Forum Discussion

dfowlkes's avatar
dfowlkes
Icon for New Contributor rankNew Contributor
4 years ago

MSI Interrupts with Qsys

I am using a Stratix IV FPGA development kit. I have instantiated an IP Compiler PCIe core along with some custom logic. Since I'm using Qsys, I'm using the CRA port connected to BAR3 to configure ...
dfowlkes's avatar
dfowlkes
Icon for New Contributor rankNew Contributor
4 years ago

Hi skbeh!

Thanks for the quick response. I mentioned in my post that interrupts do work when I use the msi_app_req line from the msi_interface, so I'm confident that the PCIe configuration space settings are correct. If they weren't, I doubt that interrupts would ever work. My issue is that when I do request an interrupt, I get more than one (15).

I think I found out today why I'm seeing so many excess interrupts though. I created an interrupt request portion of my design that requests an interrupt once every second using the msi_app_req line. Each request resulted in exactly one interrupt and one call to my interrupt handler routine. This is exactly the functionality I was looking for, and it revealed to me that I was requesting interrupts too fast. With my design, the shortest interval between the interrupt requests is on the order of 100 ns or so. Whenever I run that part of the design, I get the extra interrupts.

So, now that I've somewhat figured out the cause of my problem, I'd like to know what condition should I wait for before I send the next request. I ask because I assumed that the interrupt acknowledge bit (msi_app_ack) would assure me that I was free to submit the next request. This turned out to NOT be the case, as my current design requests the next interrupt only after having received the acknowledgement signal on msi_app_ack. So, if you could answer that question for me, I would really appreciate it. As a follow up to that, I have not been able to produce an interrupt that calls my interrupt handler with a different MessageID (vector). Am I correct in assuming that the msi_app_num[5] signal is the value to change if I want to see a different MessageID (vector)?

If you could answer those two questions for me, that would be great. Thanks again for the timely response. It is greatly appreciated!!!

  • skbeh's avatar
    skbeh
    Icon for Contributor rankContributor
    4 years ago

    When the Hard IP asserts app_msi_ack, it just means the HIP has created the interrupt message and sent out. It does not mean the message is really out of the FPGA. The HIP can't know when the packet is really out of the TX pin. Second, it absolutely does not mean the host has serviced the interrupt.
    Below describe the interrupt flow:
    1. The application asserts the interrupt app_msi_req to the HIP.
    2. The HIP creates an interrupt message and sends it to the host via the PCIe link.
    3. The HIP gives a high pulse at the signal app_msi_ack to inform the application that the interrupt is generated.
    4. The host side receives the interrupt, run the interrupt service routine, in the service routine, the software does what it needs to do. (Different application has different way to do the communication. Dependent on how users design their product).

    The app_msi_num represents the interrupt vector. The app_msi_num could be between 0~31 (1 is the default value).