iforce CSR realted questions

[just-for-fun-too]

My understanding of the iforce CSR is as follows:

When software writes a 1 into this register and the following is true: 
        (domaincfg.IE == 1) & (domaincfg.DM == 0  &  idelivery == 1) 
an interrupt is asserted to the corresponding hart.

1. Is this interrupt forced irrespective of the threshold, priority, etc., or are those considered, and only when it becomes the “current highest-priority pending-and-enabled interrupt targeted to this hart that also exceeds the priority threshold specified by ithreshold” is the interrupt forced?

2. Are topi and, as such claimi CSRs updated appropriately based on the interrupt being forced by iforce, or they not updated?

3. Now topi and as such claimi CSRs will only be zero when there is no current highest priority pending and enabled interrupt that exceeds the priority threshold. As such, only then will a read of claimi return a zero, and as such, iforce will be cleared. Is this correct?

4. Given all this, the statement in Section 4.8.1.2, first paragraph, last sentence:

    “When topi is zero, this creates a spurious external interrupt for the hart.” 
   

   is not clear.

   If topi is zero and you set iforce = 1, you end up asserting an interrupt (if the answer to 2 is a yes.) Once the interrupt is asserted, topi will get updated and will not be zero. So it's not clear what the above statement in the specification implies? My point is once the iforce-caused interrupt (spurious interrupt) gets asserted, topi is not zero.

   Or is it just being implied by the specification that, given that topi was zero (no real external interrupt meets the criteria of asserting an interrupt), an iforce assertion is asserting an external interrupt and, as such a “spurious external interrupt” is being generated?

5. The next question then is how does iforce get cleared? How does topi end up becoming zero after iforce has been asserted so that reading a zero value in topi clears iforce? Furthermore, does the iforce created interrupt also get affected by the soucecfg.SM field and treated appropriately as an edge-triggered or a level-triggered “external interrupt”?

Thanks!

[jhauser-us]

An interrupt caused by iforce has no source number or priority. (There is nowhere to configure these things for it.) Hence, there is no way to compare its priority against ithreshold.

The value of iforce has no effect on the value of topi.

Now topi and as such claimi CSRs will only be zero when there is no current highest priority pending and enabled interrupt that exceeds the priority threshold. As such, only then will a read of claimi return a zero, and as such, iforce will be cleared. Is this correct?

Correct.

Given all this, the statement in Section 4.8.1.2, first paragraph, last sentence: “When topi is zero, this creates a spurious external in interrupt for the hart.” is not clear.

The interrupt is considered spurious because it is not caused by any incoming source interrupt.

My point is once the iforce-caused interrupt (spurious interrupt) gets asserted, topi is not zero.

Incorrect. If iforce = 1 and there is no other interrupt to be delivered, then topi will be zero. The document's description of the value of topi is correct in ignoring iforce.

Please note the following from Section 4.8.2, "Interrupt delivery and handling":

When domaincfg.IE = 1 and interrupt delivery is enabled (idelivery = 1), the interrupt signal is asserted whenever either register iforce or topi is not zero.

And then:

Due to likely delay in the communication between an APLIC and a hart, it may happen that an external interrupt trap is taken, yet no interrupt is pending and enabled for the hart when a read of the hart’s claimi register actually occurs. In such a circumstance, the interrupt identity reported by the claim will be zero, resulting in an apparent spurious interrupt from the APLIC. Portable software must be prepared for the possibility of spurious interrupts at the APLIC, which can safely be ignored and should be rare. For testing purposes, a spurious interrupt can be triggered for a hart by setting an IDC structure’s iforce register to 1.

The value of iforce can be cleared either by writing a zero to the register, or by reading claimi when it is zero.

[just-for-fun-too]

Thank you for your detailed answers and clarifications - this was very helpful!

A few other related questions:

1. Because of the presence of topi in the IDC, I assumed, incorrectly, that the interrupt generated by asserting iforce would take the attributes from the IDC. I presume that the only attribute it takes from the IDC is the hart and the hart type to which the iforce-generated interrupt will be signaled. Is this correct?

2. Furthermore, because the main purpose of the iforce CSR is to use it for testing, I presume it would not be recommended/advisable to use iforce in a system where the corresponding actual interrupt is enabled to avoid the case of both the actual interrupt and the iforce interrupt occurring together. Hence, the implementation shouldn’t do anything special for the case of simultaneous assertion of “two interrupt" signals (actual interrupt and iforce-related interrupt.) Is this correct?

3. A CPU-related interrupt question: Is it possible for the external interrupt minor identities to be passed to the CPU via the mtval register? The RISC-V Privileged Architectures specification in section (3.1.16 for machine level) says:

“For other traps, mtval is set to zero, but a future standard may redefine mtval setting for other traps.”

Now the AIA specification doesn’t mention anything specifically about mtval. So the minor identity number should only be obtained by reading the claimi register. Is this correct?

Thanks.