[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] ARM IRQ Generation

From: Karthik
Subject: Re: [Qemu-devel] ARM IRQ Generation
Date: Wed, 25 May 2016 18:21:34 +0530

Okay. Thank you.

Best regards,

On Wed, May 25, 2016 at 6:18 PM, Peter Maydell <address@hidden>

> On 25 May 2016 at 13:42, Karthik <address@hidden> wrote:
> > Okay, understood. I`ll hold the IRQ line until CPU acknowledges the
> > interrupt.
> >
> > By the way, is there a distinction between edge and level triggered
> > interrupt in the qemu or it is up to the emulation implementation?
> In QEMU, if you call qemu_set_irq(irq, 1) this is equivalent to
> the hardware taking the IRQ wire to logical 1. Calling
> qemu_set_irq(irq, 0) is taking the wire to logical 0.
> (qemu_irq_pulse() takes the wire very briefly to logical 1, and
> is a bit of an odd thing to do.) You need to do what the hardware
> does to the hardware irq wire in the same situations when the
> hardware changes the irq wire state.
> Edge vs level is about what a device does when it sees a change
> in state on an an incoming interrupt wire. "Edge triggered" means
> it cares about the 0->1 change, and implies that it has an
> internal latch which is set when the edge is detected, so that
> it doesn't matter if the incoming wire drops to 0 again. "Level
> triggered" means that it is the level state of the incoming wire
> that matters. This is again all about "how do you behave when
> you see the wire state changing", and you need to do what the
> hardware does. If the hardware is strictly edge-triggered then
> your model should be also; if it is always level-triggered then
> your model must do the same; if it is configurable then again
> you need to model the configurability.
> thanks
> -- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]