Why do I see intermittent device recovery failures with error code 0x3ff in ASx4 configuration mode with HPS?
Description When configuring Agilex® 5 or Agilex® 3 SoC FPGAs in Active Serial x4 (ASx4) mode, intermittent device recovery failures with error code 0x3ff may occur if the mailbox interface is under heavy usage from the Hard Processor System (HPS). This issue is more likely to happen when nCONFIG is toggled multiple times in quick succession, particularly under stress or repeated reconfiguration scenarios. Resolution To minimize the chance of this error: Reduce mailbox traffic from the HPS during configuration and reconfiguration. If error 0x3ff occurs, reassert nCONFIG and attempt to reconfigure the device. In rare cases, if the error persists, a full power cycle of the device may be required to restore normal operation. The problem has been fixed starting with Quartus® Prime Pro Edition software version 25.3. For more details on configuration modes refer to the Device Configuration User Guide: Agilex® 5 FPGAs and SoCs or Device Configuration User Guide: Agilex® 3 FPGAs and SoCs, for error handling refer to Agilex® 5 Hard Processor System Technical Reference Manual or Agilex® 3 Hard Processor System Technical Reference Manual.Why does the RSU update cause the HPS to hang in Stratix® 10 FPGA devices with bitstreams containing large fabric designs from Quartus® Prime Pro version 25.1.1 and earlier?
Description Due to a problem in the calculation of a timeout value by the System Design Manager (SDM) firmware during the Remote System Update (RSU) process in Stratix® 10 FPGA devices, the Hard Processor System (HPS) hangs because of an SDM timeout expiration. The timeout is determined by multiplying the fabric design size in the bitstream by 10,000 and storing the result in a 32-bit variable. For large fabric designs, this value exceeds the 32-bit limit, causing it to wrap around to a smaller number. This leads to a short timeout value, and therefore a timeout expiration. The problem occurs in the FPGA Configuration First boot mode and affects Quartus® Prime Pro Edition releases 25.1.1 and earlier with bitstreams from those releases. Resolution The problem has been fixed starting with Quartus Prime Pro Edition software version 25.3.Why are there unexpected timing paths with HPS EMAC clocks in the timing report when HPS EMAC is routed to the FPGA?
Description Due to a problem in the Quartus® Prime Pro Edition Software version 24.1 and earlier, you may see unexpected timing paths in the timing report for EMAC clocks when HPS EMAC is routed to the FPGA. Resolution The top entity below helps to understand the EMAC clocks, "emac1_gtx_clk" and "user0_clock_clk" used in the design, where EMAC1 is routed to the FPGA: To work around this problem, use the following SDC constraints: set_false_path -fall_from emac1_gtx_clk -rise_to emac1_gtx_clk set_false_path -fall_from emac1_gtx_clk -rise_to user0_clock_clk Additional Information The problem will be fixed in a future release of the Quartus® Prime Pro Edition Software.Why does EMIF for HPS LPDDR4 fail calibration on the Agilex® 5 FPGA and SoC FPGA?
Description In the Quartus® Prime Pro Edition Software 24.3, when configuring the Agilex® 5 FPGAs and SoC FPGAs with the EMIF for HPS IP and LPDDR4 device implemented as dual rank (2 chip selects), dual channels (i.e., 4 dies each being 16 Gbit in density), calibration can fail. Resolution This issue is fixed in 24.3.1 Quartus® Prime Pro Edition Software release. quartus-24.3-0.11-windows.exe quartus-24.3-0.11-linux.run quartus-24.3-0.11-readme.txtWhy does the MIPI link fail despite successful FPGA reconfiguration (Phase 2) in HPS First boot mode on Agilex® 5 or Agilex® 3 SoC FPGAs?
Description For HPS First Agilex® 5 or Agilex® 3 SoC FPGAs designs that include shared IO in the HPS EMIF banks, a firmware problem may cause the MIPI link to fail. This is due to the shared IO potentially getting stuck in reset after FPGA reconfiguration (Phase 2). This failure is not observed for FPGA First designs or designs that do not use shared IO. Refer to 3.5. Agilex® 5 EMIF IP for Hard Processor Subsystem (HPS) or A.1.13.1. Restrictions on I/O Bank Usage for Agilex® 3 EMIF IP with HPS for more information regarding IO sharing. Resolution The problem has been fixed starting with Quartus® Prime Pro Edition software version 25.3.
Why does FPGA configuration (Phase 2) fail in HPS first boot mode on Agilex® 5 and Agilex® 3 SoC FPGAs when using Quartus® Prime Pro Edition Software version 25.3.1?
Description Due to a problem in Quartus® Prime Pro Edition Software version 25.3.1, Phase 2 configuration (FPGA fabric configuration from HPS) may fail on Agilex® 5 and Agilex® 3 FPGA devices when Phase 1 and Phase 2 bitstreams originate from different designs or design revisions. This is caused by HPS IO hash mismatches between compilations. Resolution To work around this problem, download and install the patch below. You must recompile both the design generating the Phase 1 bitstream and the design generating the Phase 2 bitstream using the patched version of Quartus® Prime Pro Edition Software version 25.3.1. The problem has been fixed starting with Quartus® Prime Pro Edition software version 26.1. Additional Information HPS IO hash mismatches can also occur for other reasons independent of this Quartus® Prime Pro Edition Software problem. For more information about other potential causes and how to avoid them, refer to the HPS IO Hash Compatibility section in the Hard Processor System Booting User Guide: Agilex™ 3 and Agilex™ 5 SoCsWhy does Agilex® 5 FPGA fail to boot Linux* from eMMC when using the ATF-to-Linux direct boot flow in the 26.1 release?
Description Due to an issue with the SDRAM memory configuration in the Linux device tree, the Agilex® 5 FPGA HPS fails to boot Linux* from eMMC when using the ATF-to-Linux direct boot flow in the 26.1 release (Linux branch socfpga-6.18.2-lts). This issue is not observed in the U-Boot–to-Linux boot flow, as U-Boot patches the Linux device tree with the correct memory configuration. In the ATF-to-Linux direct boot flow, ATF does not perform this patching; therefore, the memory configuration must be correctly defined in the device tree. Resolution To work around this issue, the Linux device tree used for booting from eMMC in the ATF-to-Linux direct boot flow must be updated with the correct memory configuration. For the Premium Development Kit (ES and production), this requires updating the file arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_emmc_atfboot.dts with the following fix: memory { device_type = "memory"; reg = <0 0x80000000 0 0x80000000>; }; Refer to the following build instructions for the workaround implementation: PDK 065B ES PDK 065B PDK 065A This problem is scheduled to be fixed in a future release of the Quartus® Prime Pro Edition Software.Why is the FPGA fabric unable to access the QSPI device through the SDM mailbox when ATF is used as the HPS bootloader in release 26.1 and earlier?
Description Due to the current implementation of Arm Trusted Firmware (ATF), BL31 retains ownership of the QSPI device after HPS boot in flows where ATF is used as the HPS bootloader (for example, ATF-to-Linux direct boot flow or bare‑metal boot flow). As a result, the FPGA fabric is unable to access the QSPI device through the SDM mailbox. This issue is observed in ATF releases 26.1 and earlier and affects Agilex® 7 FPGA, Agilex® 5 FPGA, and Agilex® 3 FPGA devices. Resolution There is no workaround for this issue. For Agilex® 5 FPGA and Agilex® 3 FPGA devices, this problem will be addressed in a future release by introducing an ATF build‑time switch that allows control over whether QSPI ownership is retained by or released from the HPS.Why does the HPS boot up delay after trigger HPS cold reset via the external reset pin?
Description Due to a problem in the Quartus® Prime Pro Edition Software version 24.2, when the multi-flash support feature is introduced, the flash recovery flow tries to recover the flash by re-attempting the calibration step before resetting the flash. This recovery approach causes the flash recovery flow to fail, then triggers the watchdog timer. Resolution The fix is to remove the re-calibration step and reset the flash device during the flash recovery flow. This problem is scheduled to be fixed in a future release of the Quartus® Prime Pro Edition Software.Why the Agilex® 5 FPGA Hard Processor System CoreSight Trace is not working?
Description Due to a problem in the Quartus® Prime Pro Edition Software version 25.3, when enabling the Agilex® 5 FPGA Hard Processor System Coresight Trace it is not functioning. Resolution To work around this problem, enable either one of the fabric debug feature such as APB or JTAG and tie off the signals if they are not used. The problem has been fixed starting with Quartus® Prime Pro Edition software version 26.1.
