Terasic Apollo S10 SOM board_FA

That's a genuinely frustrating situation, and I want to give you some useful technical context that may help clarify where the actual problem lies and what a reasonable resolution path looks like.

The FPGA PCIe endpoint is CPU-agnostic by design

PCI Express is a hardware interface standard. The Stratix 10 SX FPGA on your Apollo S10 SOM (OPN: 1SX280H) "Apollo S10 SoM" acts as a PCIe endpoint — it speaks to the host system's root complex over a standardized electrical and protocol interface. The PCIe specification makes no distinction between an AMD or Intel root complex on the host side. At the hardware level, a correctly implemented PCIe Gen 3 endpoint link should train and enumerate on any standards-compliant host platform, whether the CPU is from AMD or Intel.

Where the AMD/Intel issue actually lives

The problem you're describing — errors from the demo/test application running on an AMD system — is almost certainly in the host-side software layer: either the device driver or the demo application itself. If Terasic's demo software calls any Intel-specific CPU instructions, uses Intel chipset-specific registers, or was built/tested only against Intel platform APIs, it will fail on AMD — but that is a software portability problem, not a hardware PCIe incompatibility. The FPGA endpoint itself is not the source of the AMD incompatibility.

On the Quartus version testing request

One important data point: the Apollo S10 SOM's documented latest supported Quartus version is 20.2.0. "Apollo S10 SoM" Asking you to test Quartus Pro versions from 19.1 all the way through 23.3 — versions well beyond what's documented for this board — is not a reasonable debugging path for a PCIe host-software compatibility issue. The FPGA bitstream compiled by Quartus is loaded onto the device; it doesn't affect whether the host-side demo application runs correctly on AMD versus Intel.

Practical suggestions

• Separate the hardware from the software problem. Use a tool like a PCIe protocol analyzer or even the OS's built-in device manager / lspci (Linux) to confirm whether the FPGA endpoint is actually enumerating and linking up on your AMD system. If lspci shows the device, the hardware link is working — the issue is purely in Terasic's demo software.
• Request the driver source code from Terasic. As a purchaser of their hardware, you have a reasonable basis to request the host-side driver or at minimum ask them to fix the AMD portability issue in their software. A one-line platform-specific CPU check in their code is the kind of thing a driver engineer can resolve quickly.
• Linux as an alternative test path. If the demo is Windows-only, try running it on a Linux host. Many PCIe userspace drivers (using UIO or VFIO) are inherently CPU-architecture-neutral and can help isolate whether the issue is OS/platform-specific or FPGA-side.

You are correct that Terasic — as the board and software vendor — owns the responsibility for the host-side demo software working on commercially available platforms. Asking a customer to purchase a second computer to run test builds is not an acceptable support response. Your escalation point is well-founded: this is a Terasic software quality issue, not a user configuration error.