FPGA IRQ design question

[Grant Likely]

On Wed, Apr 22, 2009 at 8:49 AM, Eddie Dawydiuk <eddie at embeddedarm.com> wrote:
> Hello,
>
> I'm working on a board based on the Yosemite AMCC 440EP. We have an FPGA
> connected via the PCI bus, and has an IRQ line connected directly to the
> 440EP. The FPGA implements two registers to indicate which core generated
> the interrupt. So now the question is from a design standpoint is it
> preferable to setup the IRQ as a single external IRQ then have each driver
> request this same IRQ. In each ISR the driver is responsible for checking
> the FPGA registers to see if the interrupt is intended for itself. Or would
> it be preferable to modify the lower level irq routines such that multiple
> software/virtual(not sure what the right term is here) irqs are created
> corresponding to the single external IRQ. Then abstract the details of the
> FPGA interrupt registers from each driver. Such that each driver request the
> proper software/virtual IRQ and requires no knowledge of the fpga irq
> registers. Any comments would be appreciated.

Both approaches are valid and you can use your judgment here, but here
are some suggestions:

If the IRQs need to be explicity acked in the FPGA iq controller, then
I'd probably write a cascaded irq driver.  Or, if you will be using
existing device drivers, then I would also probably do a cascaded
driver.

However, if you're writing one-off custom drivers and there is no
common coded needed for acking irqs, then I would probably just use
the external IRQ.

g.