Forum Discussion

GStre's avatar
GStre
Icon for New Contributor rankNew Contributor
4 years ago
Solved

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

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

  • GStre's avatar
    GStre
    4 years ago

    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.

9 Replies

    • GStre's avatar
      GStre
      Icon for New Contributor rankNew Contributor

      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.

      • GStre's avatar
        GStre
        Icon for New Contributor rankNew Contributor

        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.

  • KhaiChein_Y_Intel's avatar
    KhaiChein_Y_Intel
    Icon for Regular Contributor rankRegular Contributor

    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


    • GStre's avatar
      GStre
      Icon for New Contributor rankNew Contributor

      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.

    • GStre's avatar
      GStre
      Icon for New Contributor rankNew Contributor

      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.

  • KhaiChein_Y_Intel's avatar
    KhaiChein_Y_Intel
    Icon for Regular Contributor rankRegular Contributor

    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


  • KhaiChein_Y_Intel's avatar
    KhaiChein_Y_Intel
    Icon for Regular Contributor rankRegular Contributor

    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