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!!!