Terasic P16E-FMCP PCIE Express 3.0 compatibility issues with AMD processors

That's a genuinely frustrating situation, and your core argument is sound — if AMD compatibility is a limitation of the demo software, that should be clearly disclosed at point of sale.

Let me give you some useful technical context from the documentation side.

**What the hardware side looks like**

The Apollo S10 SOM is built on the Stratix 10 SX FPGA. "Apollo S10 SoM" The PCIe Hard IP on that device implements a standard PCIe specification. At the hardware/silicon level, PCIe is a CPU-agnostic bus — the FPGA endpoint doesn't "know" whether the host CPU is AMD or Intel. The link trains, enumerates, and transfers data entirely based on the PCIe specification, not the CPU vendor.

**Where the AMD incompatibility actually lives**

The issue you're describing — errors in the demo program, System Information Viewer seeing endpoint responses — is almost certainly in Terasic's **host-side driver and/or BSP software**, not in the FPGA fabric or the PCIe Hard IP itself. Terasic-provided BSPs are adapted specifically for their boards FPGA AI Suite Design Examples User Guide , and the BSP provided by Terasic is OpenCL-based. Agilex® 7 FPGAs and SoCs Device Overview If that BSP or demo driver was written and tested only against Intel CPU platforms (e.g., specific IOMMU behavior, memory-mapped I/O assumptions, or DMA descriptor handling that differs between Intel and AMD chipsets), it will fail on AMD without code changes. That is a software portability problem Terasic owns.

**What you can verify on the FPGA side to rule out a hardware issue**

If you want to confirm the FPGA PCIe link itself is healthy (independent of the demo software), you can check the LTSSM state:

When link training completes successfully and the link is up, the LTSSM should remain stable in the L0 state. When link issues occur, you can monitor `ltssmstate[4:0]` to determine whether the link training fails before reaching L0, or whether the link is initially established (L0) but then stalls. Arria® V Hard IP for PCI Express* User Guide To check whether the PCIe HIP is actually receiving TLPs, you can observe the PIPE interface signals. Set trigger conditions: `test_out[24]` (rxvalid) = '1', `test_out[23]` (rxdatak) = '1', `test_out[22:15]` (rxdata) = 'fb' (K28.7, Start of TLP). If the trigger condition cannot be met, the endpoint is not sending TLPs to the PCIe HIP root port. How to determine if the PCIe HIP receives the TLP from the other side?

If your LTSSM reaches L0 and TLPs are flowing at the PIPE level, the FPGA hardware is working correctly — and the failure is definitively in the Terasic host software.

**Your position with Terasic**

You are right that you should not be doing their QA work. The practical path forward:

1. **Document that the FPGA link reaches L0** using SignalTap (this proves the hardware works and pins the bug squarely on their driver).
2. **Formally escalate in writing** that the product was sold without disclosing an AMD restriction, and that Terasic is responsible for driver compatibility under their standard support terms.
3. Altera (as the silicon vendor) does not directly control Terasic's BSP/driver software — that is Terasic's responsibility as a partner — but Altera's partner program does have escalation channels if Terasic is unresponsive to a valid support issue.

The FPGA PCIe Hard IP conforms to the PCIe specification and is not inherently AMD-incompatible. The fix Terasic needs to make is in their host driver, not in your hardware or your test setup.

Note: To continue using AI Responder, please start your next inquiry with ai_responder

Disclaimer (Beta): The AI Responder is currently provided as a beta feature. AI-generated responses may contain errors or omissions. Please verify technical guidance with official Altera documentation before implementation.

Thank you very much.