(SR-IOV is "not" enabled) When I enable MSI-X support I can't get the conduit for those signals to show up in Platform Designer, only the MSI signals. I enabled that support but nothing is generated (RTL) that has the msi-x signals. I do get those signals when I use the SR-IOV hardcore. We'd rather use the non-SR-IOV in one instance.
Added edit: FYI - this is a version 18.0 pcie_a10_hip core.
Update: 12/04/18 - I was looking into a few of my questions further (besides this port), some thoughts:
With an Avalon-MM DMA environment selected the MSI-X signals appear at the application layer (when enabled), along with additional control signals I can see in an errata but not in the manual's signal list (such as msix_control[15:0]).
What do you mean by SR-IOV hardcore. Could you provide a snapshot of the IP you are referring to as SR-IOV hardcore, SR-IOV "not enabled". I am looking into this case but have difficulties to understand the terms used. Hence, it will be useful if you could provide the snapshots of the IP so I could understand better and provide an explanation or guideline.
When you open an Arria10 project in Quartus Prime Pro, Tools-> Platform Designer, you have your qsys with (in our case) a qsub_pcie_inst, drill into that and you can modify the parameters of the pcie_a10_hip_inst. For System Settings (Parameters main tab) you can select the Application interface type: "Avalon-ST" or "Avalon-ST with SR-IOV" (only two choices in PD). If you select Avalon-ST, on the "PCI Express/PCI Cabilities" tab you select "Implement MSI-X", which enables it, and then you select its settings, then you save and Generate HDL. The generated RTL's int_msi Conduit does not contain the MSI-X signals (app_msix_req/ack/etc). If I had chosen the "Avalon-ST with SR-IOV" "Application interface type" under "System Settings" and did the same (with different tabs) the app_msix_... signals are exposed to the application layer. I'll try to show the two in images, assuming that is what you mean by "snapshots of the IP"(?). Note that the generated top-level(s) either have the msix signals or not depending on the above settings.
Update: 12/04/18 - I was looking at the MM-DMA link you gave me; with an Avalon-MM DMA environment selected the MSI-X signals appear at the application layer (when enabled), along with additional control signals I can see in an errata but not in the manual's signal list (such as msix_control[15:0]).
Now i understand your problem better. When you select interface type "Avalon ST" you are not able to see the MSI-x signals but when select Avalon St with SR-IOV you are able to see them.
Its because the Avalon-ST interface enables MSI-X interrupts differently then Avalon-ST interface with SR-IOV whereby the conduits or MSIx interrupt signals are only offered in the Avalon-ST interface with SR-IOV only.
This is covered in our documentation. If you only intend to use Avalon-ST, then you may refer to Implementing MSI-X Interrupts in our user guide.
For Avalon-ST interface, please refer to the following user guide:
For Avalon-ST with SIOV interface, please refer to the following user guide:
Yes, I figured that out last night; for the Avalon-ST without SR-IOV the MSI-X interrupts need to be generated on the ST interface, not the convenient MSI-X signals the SR-IOV version supports (a pain having to have `ifdef(s) to change functionality and pinout, though I'll just resign myself to not using that MSI-X interface on the SR-IOV version and just using write-TLPs). As the Intel documentation says "The Application Layer transmits MSI-X interrupts on the Avalon-ST TX interface. MSI-X interrupts are single dword Memory Write TLPs".
Consider this issue closed.