Re: Question about edge-triggered interrupt

[Alistair Francis <alistair23@gmail.com>]

On Thu, Mar 11, 2021 at 11:21 AM LIU Zhiwei <zhiwei_liu@c-sky.com> wrote:
>
>
>
> On 2021/3/11 21:17, Peter Maydell wrote:
> > On Thu, 11 Mar 2021 at 12:59, LIU Zhiwei <zhiwei_liu@c-sky.com> wrote:
> >>  From the specification, I find that software will not clean the pending bit on interrupt controller via a register write.
> >>
> >> "When a vectored interrupt is selected and serviced, the hardware will automatically clear the
> >>
> >> corresponding pending bit in edge-triggered mode. In this case, software does not need to clear
> >>
> >> pending bit at all in the service routine."
> >>
> >> Hardware can always select a pending interrupt as it is cycle-driven. But QEMU is event-driven.
> >> I don't know if there is a chance to select other pending interrupts after serving the selected interrupt.
> > Something must change that the hardware (and thus the model) can use to
> > determine that it needs to do something else. The interrupt controller
> > must be able to tell when the interrupt is "selected and serviced"
> > somehow.
> That's a case I can't understand.
>
> 1.  An device causes an edge-triggered interrupt A.
> 2.  The interrupt controller sample the interrupt A, and setting pending
> bit for A.
> 3.  The interrupt controller select the interrupt  A to CPU and clean
> the pending bit for A(according to the specification).

I'm not a CLIC expert but from what I can tell I think the interrupt
is only cleared after being read.

The key lines in the spec are:

"When a vectored interrupt is selected and serviced, the hardware will
automatically clear the corresponding pending bit in edge-triggered
mode."

and

"The xnxti CSR can be used by software to service the next horizontal
interrupt..."

The C-ABI code (https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc#81-c-abi-trampoline-code)
seems to say something similar


    csrrsi a0, mnxti, MIE   # Get highest current interrupt and enable
interrupts.
                            # Will return original interrupt if no
others appear. (6)

Does that sound right?

Alistair


> 4.  CPU start to execute the A's service routine.
> 5.  Another device causes interrupt B.
> 6.  The interrupt controller sample the interrupt B, and setting pending
> bit for B.
> 7.  As B's priority is lower than A, it can't preempt  A's service routine.
> 8.  A's service routine return.
> 9. No other interrupt comes after B.
>
> After the sequence, B is pending in interrupt controller, and has no
> chance to be selected by interrupt controller.
> A's service routine will neither write interrupt controller's register
> nor device's register.
>
> In my RTOS case, the interrupt A here is really a software interrupt.
> Just for clarity here.
>
> Thanks for sharing your ideas.
>
> Zhiwei
> >
> > thanks
> > -- PMM
>
>