Quartus P-Tile PCIe IP config crashes

I am working with multiple platforms that have PCIe interconnect as the only available control-plane interaction. These are deployed systems, so a design constraint is to use the existing memory-mapped PCIe control paradigm. The host controller sets operating parameters via memory-mapped port writes, reads machine status via port reads, responds to interrupts on the various cards, and blinks LEDs ... you know, normal hardware-system tasks. The target cards are big state machines with no local processor.

The system does not operate with DMA-anything. We are not transferring blocks of data in a packet/protocol structure. We disabled the DMA data movers because they have zero place in our system architecture. We just need memory-mapped control ports, and legacy interrupts to trigger event responses. We have these operational with Stratix 10 and Cyclone 10 FPGAs, and they work fine. We are migrating to an Agilex-based design, and that's where we bashed into the P-Tile support issue. Functionally, the P-Tile should be able to handle a memory-mapped Avalon interface.

We found this bit in the documentation disturbing -

Note: Do not use the P-tile Avalon® Memory-mapped IP for PCI Express* for new designs. This IP will not be available in future releases of Intel® Quartus® Prime. For new designs, use the Multi-Channel DMA IP.

(ref: https://www.intel.com/content/www/us/en/docs/programmable/683853/21-1-4-0-0/design-example-overview.html )

Not sure why Intel/Altera would think that there's no place for direct-mapped port-I/O construct in a hardware-based platform ...

Intel is deprecating the PCIe Avalon-MM IP core, and recommends not-using it in new designs. (Post #4, above.) In the immediately following sentence, Intel recommends that customers should use the MCDMA core instead. I explored the possibility of using it.

My application performs reads and writes to memory-mapped ports in response to interrupts from the target device. Think "closed loop feedback machine control" and not "streaming cat videos." We currently implement interrupt support via the legacy MSI functions. Our host system is running an interrupt-driven executive.

The MCDMA IP core does not appear to support MSI. However there is an MSI-X tab, which suggests that interrupts could be implemented via the message-based construct, albeit with a substantial increase in level-of-effort to do so. Unfortunately, MSI-X support appears to be "not functional." Intel's recommended "use the MCDMA core" is only a solution for a subset of the customer base who don't use interrupts ...

Well, I thought I would try to work within the system rather than fight it. Opened a new, clean design and instantiated the PCIe Avalon-MM IP core. My thought process - leave the existing DMA / memory-mover construct in place, and just spackle-on an I/O port construct.

Found that making any change to a parameter crashes the elaborator script. The attached screen grab shows the result of changing only the Revision ID field ... you know, something that you would want to update when you change the contents of the design. Tested this in both 22.3 and 22.4 versions of Quartus Pro.

That's a very bot-like reply, though it's probably a hot-key-mapped scripted response. Likely, your hand is hovering over the key to issue:

• We have not hear from you and this Case is idling. It is not recommended to idle for too long.
• Therefore following our support policy, I have to put this case in close status. My apologies if any inconvenience cause
• Hence, This thread will be transitioned to community support.

You've verified that the problem exists, but "talk to your sales rep" isn't much "help."

If you're inclined to punt this into Community Support mode, you'll need to publish the P-Tile API so we community members can do something with it. The P-Tile lives between the FPGA fabric and the PCIe pins, so we can't bypass the P-Tile with a custom design.

Wow, it's a carbon-copy from my post on 2/21. Is that <Alt><F3> or <Alt><F5>? (or more likely one followed by the other?)

Two days "idling", then scraped off your shoe. Nice. Nothing says "please go away" like being transitioned to community support.

The demo design included with the PCIe Avalon-MM core produces a Platform Designer entry that has a "generic component" instead of the PCIe core proper. This Generic Component appears to have all of the 2000-ish P-Tile parameters unrolled as a flat file (further evidence that Intel/Altera knows the PCIe Avalon-MM core generator is broken.) While no doubt comprehensive, this is not particularly useful unless you have the P-Tile API document that describes all of the various parameters and their inter-relationships. Any chance Intel/Altera can publish the API so we, the community, can move forward? The P-Tile hardware supports the Avalon-MM interface. The script generating the parameters is broken. Intel/Altera doesn't want to support it. Give me the ability to fix it myself.