FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6343 Discussions

Exported MSI conduit on A10 PCIe AVMM IP is non-functional

GStre
New Contributor I
801 Views

The A10 PCIe IP core allows you to export msi interrupt signals, msi_interface[81:0] and msi_control[15:0]. These signals are described in UG-01145_AVMM document and are required if you are going to write your own MSI interrupt handler. These two exported conduits are supposed to reflect the msi configuration space registers, specifically address 0x50 thru 0x5C. The root complex writes to these registers to enable MSI interrupts and provides the endpoint with MSI information like allocated number of vectors, message address and message data. The problem is, this information is not being updated on these two conduits after the root complex writes to these configuration space registers. Using signal tap I can see the data on these two conduit ports and using some application software I can read the MSI registers in configuration space. The conduit interfaces are not being updated. For this PCIe AVMM application, we are using 64-bit addressing and MSI interrupts with 16 vectors requested. The documented results are provided below.

msi_control[15:0] = 0x0088

msi_interface[81:0] = 0x0000000000000

MSI Configuration Registers are:

Address 0x50 = 0x0089_7805    (Capability, Next Pointer and Message Control)

Address 0x54 = 0xFEE0_0000    (Lower 32-bits of the MSI Address)

Address 0x58 = 0x0000_0000    (Upper 32-bits of the MSI Address)

Address 0x5C = 0x0000_40A9    (Message Data)

As you can see, the root complex has enabled MSI interrupts with 1 vector granted but this is not reflected on the MSI conduit signals. The exported MSI conduit bus is useless. By the way, this all works in simulation. I'm using Quartus Prime Pro version 18.1

0 Kudos
1 Solution
GStre
New Contributor I
785 Views

KhaiY,

I'm sorry, due to ITAR, IP and other matters, this design cannot be shared. Although it's easy enough to put together your own simple design. The fact is, the MSI conduit interface simulates properly in version 18.1, it's the actual hardware that don't work. Another interesting fact is that in earlier versions of Quartus the MSI conduit simulation did not work, which back then, when you could,  I pulled a Altera ticket. So I'm not surprised to see the hardware non-functional. 

 

View solution in original post

0 Kudos
9 Replies
KhaiChein_Y_Intel
791 Views

Hi,


Could you share the simulation result and signal tap?


Thanks

Best regards,

KhaiY


0 Kudos
GStre
New Contributor I
786 Views

KhaiY,

I'm sorry, due to ITAR, IP and other matters, this design cannot be shared. Although it's easy enough to put together your own simple design. The fact is, the MSI conduit interface simulates properly in version 18.1, it's the actual hardware that don't work. Another interesting fact is that in earlier versions of Quartus the MSI conduit simulation did not work, which back then, when you could,  I pulled a Altera ticket. So I'm not surprised to see the hardware non-functional. 

 

0 Kudos
GStre
New Contributor I
762 Views

KhaiY,

I disconnected the MSI conduit conduit from my interrupt handler and made another build, but still monitored it using signal tap. This time the conduit worked and took on the values of the MSI configuration registers after enumeration. I then modified my interrupt handler by adding additional input registers to isolate the conduit interface and made another build. Once again, the MSI conduit worked! With all these builds and testing, I never regenerated the Qsys block, only my application code of the interrupt handler. I can only hope this conduit interface sticks on future builds.

 

0 Kudos
KhaiChein_Y_Intel
746 Views

Hi,


It's glad to hear that the MSI conduit is working now.

From your previous reply, it seems like the problem is on the application code of the interrupt handler. Could you share more details about the fix? Is it only disconnecting the MSI conduit from the interrupt handler?


Thanks

Best regards,

KhaiY


0 Kudos
GStre
New Contributor I
736 Views

I disagree, the problem is with the compilation of the machine generated code in the Qsys Platform designer block. The notion that the conduit interface would break-down on some user interface dependency is garbage. I essentially did nothing to fix this interface other than add a few registers and re-complied it again. It failed once and I expect it to fail again in future builds.  

 

 

 

0 Kudos
KhaiChein_Y_Intel
729 Views

Hi,


Is there any timing violation in the design?


Thanks

Best regards,

KhaiY


0 Kudos
GStre
New Contributor I
719 Views

Hi,

There was never a timing violation, look at the failure condition.  The default power-up state of the MSI configuration registers are reporting correctly but they are never updated after the root complex enumerates the FPGA endpoint. I know it would be convenient to write this off to operator error, don't see it. 

0 Kudos
KhaiChein_Y_Intel
711 Views

Hi,


If you can see the data on the conduit ports using signal tap and read the MSI registers in configuration space, I think there is no problem in the FPGA PCIe endpoint. The problem happens after the root complex enumeration and modifying the application code of the interrupt handler without Qsys regeneration fixed the problem.


Thanks

Best regards,

KhaiY


0 Kudos
KhaiChein_Y_Intel
691 Views

Hi,


Since there is no other questions, this thread will be transitioned to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you


Best regards,

KhaiY


0 Kudos
Reply