Asserting one or more bits of
xdma0_usr_irq_req when legacy interrupts are enabled causes the IP to
issue a legacy interrupt over PCIe. Multiple bits may
be asserted simultaneously but each bit must remain asserted until the corresponding
xdma0_usr_irq_ack bit has been asserted. After a
xdma0_usr_irq_req bit is asserted, it
must remain asserted until the corresponding
xdma0_usr_irq_ack bit is asserted and the
interrupt has been serviced and cleared by the Host. The
xdma0_usr_irq_ack assertion indicates the
requested interrupt has been sent on the PCIe block.
This will ensure interrupt pending register within the IP remains asserted when queried
by the Host's Interrupt Service Routine (ISR) to determine the source of interrupts. You
must implement a mechanism in the user application to know when the interrupt routine
has been serviced. This detection can be done in many different ways depending on your
application and your use of this interrupt pin. This typically involves a register (or
array of registers) implemented in the user application that is cleared, read, or
modified by the Host software when an interrupt is serviced.
After the
xdma0_usr_irq_req bit is deasserted, it cannot be reasserted until the
corresponding
xdma0_usr_irq_ack bit has been asserted for a second time. This indicates
the deassertion message for the legacy interrupt has been sent over PCIe. After a second
xdma0_usr_irq_ack occurred, the
xdma0_usr_irq_req wire can be reasserted
to generate another legacy interrupt.
The
xdma0_usr_irq_req bit can be mapped to legacy interrupt INTA, INTB, INTC,
INTD through the configuration registers. The following figure shows the legacy
interrupts.
This figure shows only the handshake between
xdma0_usr_irq_req and
xdma0_usr_irq_ack. The user application
might not clear or service the interrupt immediately, in which case, you must keep
xdma0_usr_irq_req asserted past
xdma0_usr_irq_ack.