Why do I see Error (18950), Error (18948) and Error (209012) when program SOF file for Agilex® 5 FPGA device in Quartus® Prime Pro Edition version 26.3 ?
Description You may encounter programming failure in Quartus® Prime Pro Edition Software version 26.3 with an Agilex® 5 FPGA device SOF File. The operation fails with the following errors: Error(18950): Device has stopped receiving configuration data Error(18948): Error message received from device: Failed to load firmware due to authentication failure. Ensure the firmware is signed with the correct signing key. Error(209012): Operation failed Impacted Agilex 5 OPN A5Dx130xxxxxxxx A5Dx160xxxxxxxx Resolution Contact Altera Support team for the patch file. Related Article Agilex® 5 FPGA Part Number DecoderWhy does the GTS AXI Streaming IP for PCI Express* on Agilex® 5 FPGA D-Series remain in reset or fail to initialize after system boot?
Description Due to a problem in the Quartus® Prime Pro Edition software version 26.3, the GTS AXI Streaming IP for PCI Express* on Agilex® 5 FPGA D-Series devices may not initialize successfully. Devices programmed with a .sof file or an image generated by version 26.3 may exhibit the following symptoms: The PCIe IP remains in reset. The PCIe endpoint fails to enumerate. These symptoms may occur even though device configuration and overall system boot-up have completed successfully. Impacted Agilex 5 OPN A5Dx130xxxxxxxx A5Dx160xxxxxxxx Resolution This problem is scheduled to be fixed in a future release of the Quartus Prime Pro Edition software.Why does the bas_axi_mm_rlast signal of the GTS AXI MCDMA IP not asserted on the final beat of a read burst?
Description Due to a problem in the Quartus® Prime Pro Edition software version 26.3 and earlier, the GTS AXI Multichannel DMA IP might fail to assert bas_axi_mm_rlast on the final beat of a multi-beat AXI read burst or may assert it on an earlier beat. This problem occurs in the Bursting Slave (BAS) read-response path for multi-beat PCIe completion, potentially causing an AXI protocol violation or an incorrectly terminated read burst. Resolution This problem is scheduled to be fixed in a future release of the Quartus Prime Pro Edition software.Why do I see a generation failure with simulation enabled, or a compilation failure, in the Integrated PHY Dual-Simplex Serial Loopback design example with TX Clock Switching?
Description Due to a problem in the Quartus® Prime Pro Edition software version 26.3, you may see the following problems when generating or compiling the Integrated PHY Dual-Simplex Serial Loopback design example with TX Clock Switching enable: Generation failure when simulation is enabled When you enable simulation in the design example, generation fails. There is currently no workaround for this problem. This problem is scheduled to be fixed in a future release of the Quartus Prime Pro Edition software. Compilation failure when simulation is disabled The gxb_tx_refclk_cmd_bus_in[*] ports are missing from the shared_clocks list of the TX QHIP_IP_PROPERTY assignment in the .qsf file. Because of this, compilation fails with the following error: Error (26050): IP instance port name sdi_tx_inst|gxb_tx_refclk_cmd_bus_in[n] for DR_SHARED_CLOCK assignment in dual simplex/reconfiguration group dr_top is not allowed. To fix this compilation failure, follow the workaround in the Resolution section. Resolution To work around compilation problem, user needs to add the gxb_tx_refclk_cmd_bus_in[0] to gxb_tx_refclk_cmd_bus_in[9] ports to the shared_clocks list of the TX QHIP_IP_PROPERTY assignment in qsf file. Example: "shared_clocks" : ["system_pll_clk", "system_pll_lock", "tx_pll_refclk", "gxb_tx_refclk_cmd_bus_in[9]", "gxb_tx_refclk_cmd_bus_in[8]", "gxb_tx_refclk_cmd_bus_in[7]", "gxb_tx_refclk_cmd_bus_in[6]", "gxb_tx_refclk_cmd_bus_in[5]", "gxb_tx_refclk_cmd_bus_in[4]", "gxb_tx_refclk_cmd_bus_in[3]", "gxb_tx_refclk_cmd_bus_in[2]", "gxb_tx_refclk_cmd_bus_in[1]", "gxb_tx_refclk_cmd_bus_in[0]"]}} Save the file and recompile the design.Why does the NVMe device report errors after an HPS warm reset on Agilex® 5 ES devices when FPGA reconfiguration is skipped?
Description Due to a problem in the Agilex® 5 ES devices (A5Ex065BxxxxExxR0 and A5Ex065AxxxxExxR0), the FPGA-to-HPS (F2H) bridge can fail after an HPS warm or cold reset, or after a subsequent FPGA reconfiguration, when the System Memory Management Unit (SMMU) is enabled in HPS Boot First mode. To avoid this, some PCIe* Root Port designs skip FPGA reconfiguration in U-Boot after an HPS warm reset and keep the FPGA configuration from the previous boot. When FPGA reconfiguration is skipped, the PCIe Root Port in the FPGA fabric and the attached Non-Volatile Memory Express (NVMe) endpoint are not reset. They keep stale state from the previous boot. When Linux enumerates the PCIe bus and loads the NVMe driver, the stale state might cause the NVMe admin command to time out and the NVMe driver probe to fail. The kernel log shows messages similar to: nvme nvme0: pci function 0000:01:00.0 nvme nvme0: I/O tag 24 (0018) QID 0 timeout, disable controller nvme nvme0: Device not ready; aborting shutdown, CSTS=0x5 nvme nvme0: Identify Controller failed (-4) nvme 0000:01:00.0: probe with driver nvme failed with error -5 The NVMe device still enumerates and its BAR is assigned, but /dev/nvme0n1 is not created. Refer to the section "FPGA-to-HPS (F2H) bridge, HPS warm/cold reset and FPGA reconfiguration issues with SMMU enabled" in the Agilex® 5 ES Device Errata and User Guidelines. Resolution To work around this problem on Agilex 5 ES devices, reset the PCIe Root Port secondary bus and re-enumerate the PCIe devices from Linux after an HPS warm reset. Run these commands as root: Assert a secondary bus reset by setting bit 6 of the Bridge Control register on the Root Port: setpci -s 00:00.0 BRIDGE_CONTROL=40:40 Wait, then release the reset by clearing bit 6: sleep 1 setpci -s 00:00.0 BRIDGE_CONTROL=00:40 Wait for the link to retrain, then remove the Root Port device: sleep 1 echo 1 > /sys/bus/pci/devices/0000:00:00.0/remove Rescan all PCIe buses: echo 1 > /sys/bus/pci/rescan After the rescan, Linux re-enumerates the Root Port and the NVMe device with clean state. This problem is fixed in Agilex 5 production devices (A5Ex065BxxxxExx and A5Ex065AxxxxExx). Additional Information 00:00.0 is the Root Port bus/device/function in the Agilex 5 PCIe Root Port system example design. Run lspci to confirm the Root Port address in your system and replace 00:00.0 if it differs. The setpci value 40:40 uses the value:mask format, so it changes bit 6 only and leaves the other Bridge Control bits unchanged. The PCI Express® Base Specification requires the secondary bus reset to be held for at least 1 ms, and software to wait at least 100 ms after releasing it before sending configuration requests. The sleep 1 commands above meet both requirements. An FPGA power cycle (cold boot) also resets the Root Port and the NVMe device.Why is there D2H payload mismatch on GTS AXI MCDMA IP?
Description Due to a problem in the Quartus® Prime Pro Edition software version 26.3 and earlier, the GTS AXI Multichannel DMA IP for PCI Express* might transmit D2H data associated with the wrong queue on AXI-Stream TX interface. As a result, the Host may receive data at an incorrect destination address, potentially causing transaction mismatches. Resolution This problem is scheduled to be fixed in a future release of the Quartus Prime Pro Edition software.Why is the HPS I2C SCL clock frequency above 400 kHz in fast mode when using U-Boot?
Description When the HPS I2C controller is configured for fast mode (clock-frequency = <400000>) in U-Boot, the measured SCL frequency might exceed the 400 kHz maximum in the I2C specification (for example, 431 kHz) on SoC FPGA designs. This happens because the U-Boot DesignWare I2C driver (drivers/i2c/designware_i2c.c) calculates the SCL high and low counts from assumed SCL rise and fall times. When the device tree does not specify them, the driver assumes default 300 ns for both in fast mode. The driver subtracts the assumed rise time from the SCL period. If the board's actual SCL rise time is shorter than 300 ns, the unused part of that allowance shortens the period, and SCL runs faster than 400 kHz. The Linux DesignWare I2C driver uses a different calculation and different device tree properties, so the same device tree node can give different SCL frequencies in U-Boot and Linux. Resolution To set the SCL timing to match your board, follow these steps: Measure the SCL and SDA rise times (30%–70%) and fall times (70%–30%) on your board with an oscilloscope, in fast mode. In the U-Boot device tree, add the measured values to the HPS I2C node: &i2c0 { clock-frequency = <400000>; i2c-scl-rising-time-ns = <[measured tr]>; i2c-scl-falling-time-ns = <[measured tf]>; i2c-sda-hold-time-ns = <[required hold, default 300]>; }; For Linux, add the SDA fall time to the same node. The Linux driver uses i2c-sda-falling-time-ns for the SCL high count and i2c-scl-falling-time-ns for the SCL low count, and ignores i2c-scl-rising-time-ns: i2c-sda-falling-time-ns = <[measured tf]>; Rebuild U-Boot and the Linux device tree blob, then re-measure SCL in both U-Boot and Linux to confirm the frequency is at or below 400 kHz and that tLOW ≥ 1.3 µs and tHIGH ≥ 0.6 µs. Note these points when tuning: In U-Boot, enter the actual measured rise time. A larger i2c-scl-rising-time-ns value makes SCL faster, not slower. In U-Boot, i2c-scl-falling-time-ns changes only the high/low duty cycle, not the frequency. In Linux, larger fall-time values make SCL slower. Do not lower clock-frequency below 400000 in U-Boot to slow the bus. Any value below 400000 selects standard mode (100 kHz timing). snps,bus-capacitance-pf has no effect in fast mode. U-Boot ignores it, and Linux uses it only for high-speed mode (3.4 MHz). Additional Information Property U-Boot Linux clock-frequency Sets the target SCL period (default 100 kHz) Selects the speed mode only (default 400 kHz) i2c-scl-rising-time-ns Sets the SCL frequency (default 300 ns in fast mode, 1000 ns in standard mode) Ignored by the DesignWare driver i2c-scl-falling-time-ns Changes the duty cycle only (default 300 ns) Sets the SCL low count (default 300 ns) i2c-sda-falling-time-ns Ignored Sets the SCL high count (default 300 ns) i2c-sda-hold-time-ns Sets the SDA hold time (default 300 ns) Sets the SDA hold time (default: keeps the existing hardware value) snps,bus-capacitance-pf Ignored Used in high-speed mode (3.4 MHz) onlyWhy does the Agilex® 5 FPGA E-Series 065B Modular Development Kit 10GbE System Example Design fail to boot from the SD card with "Card did not respond to voltage select"?
Description Due to a problem in the Agilex® 5 Ethernet System Example Design (SED) for the Agilex® 5 FPGA and SoC E-Series 065B Modular Development Kit (MDK, ordering code MK-A5E065BB32AEA), designed with the Quartus® Prime Pro Edition Software version 26.1 (SED release Q26.1 Rel-1.2), the Hard Processor System (HPS) might fail to boot from the SD card. After DDR calibration succeeds, the U-Boot Secondary Program Loader (SPL) reports: Trying to boot from MMC1 Card did not respond to voltage select! : -110 spl: mmc init failed with error: -95 SPL: failed to boot from all boot devices This happens for two reasons, and both must be corrected: The prebuilt SPL provided with the design (src/sw/artifacts/u-boot-spl-dtb.hex) switches the SD card I/O voltage through an HPS GPIO. On the 065B MDK, the SD card voltage is switched through the I²C GPIO expander. The SPL built by the design's own Yocto flow uses the I²C GPIO expander and works. The HPS configuration in the design does not match the 065B MDK: HPS pins HPS_IOA_1, HPS_IOA_11, HPS_IOB_4 and HPS_IOB_5 are not configured as GPIO, and the main PLL, peripheral PLL and MPU clock overrides are enabled. With this configuration, the SD card fails to initialize even with the Yocto-built SPL. Refer to the Agilex® 5 FPGA E-Series 065B Modular Development Kit 10GbE System Example Design user guide. Resolution To work around this problem in the Quartus® Prime Pro Edition Software version 26.1, follow these steps: 1. In Platform Designer, open the HPS IP (src/hw/src/ip/hps_subsys/agilex_hps.ip). In the pin mux settings, set: HPS_IOA_1 to GPIO0:IO0 HPS_IOA_11 to GPIO0:IO10 HPS_IOB_4 to GPIO1:IO3 HPS_IOB_5 to GPIO1:IO4 2. In the same HPS IP, turn off the main PLL, peripheral PLL and MPU clock overrides. 3. Export the four HPS GPIO signals from the HPS subsystem and add the matching ports to src/hw/src/top.sv. 4. Regenerate the Platform Designer systems and compile the design (make all in src/hw/synth). 5. Build the software with the design's Yocto flow: cd src/sw/yocto . agilex5_mk_a5e065bb32aes1-ETH_1P10G-build.sh build_default 6. Generate the programming files with the Yocto-built SPL instead of the prebuilt src/sw/artifacts/u-boot-spl-dtb.hex: cd src/hw/synth quartus_pfg -c -o hps=on -o hps_path=../../sw/yocto/agilex5_mk_a5e065bb32aes1-gsrd-images/u-boot-agilex5-socdk-gsrd-atf/u-boot-spl-dtb.hex output_files/top.sof output_files/top.rbf For QSPI boot, generate the JIC file with the same SPL: quartus_pfg -c output_files/top.sof output_files/top.jic -o device=MT25QU128 -o flash_loader=A5ED065BB32AE4S -o hps_path=../../sw/yocto/agilex5_mk_a5e065bb32aes1-gsrd-images/u-boot-agilex5-socdk-gsrd-atf/u-boot-spl-dtb.hex -o mode=ASX4 -o hps=1 7. Write the Yocto-built SD card image (sdimage.tar.gz) to the SD card, then program top.hps.rbf over JTAG or top.hps.jic into the QSPI flash. This problem is scheduled to be fixed in a future release of the Agilex 5 Ethernet System Example Design for the Agilex 5 E-Series 065B Modular Development Kit. Additional Information The problem was reproduced on two Agilex 5 E-Series 065B Modular Development Kit boards. The 065B Golden System Reference Design (GSRD) boots from the SD card on the same boards and SD card. Changing only the SPL, or only the HPS configuration, is not sufficient. With both changes, the design boots from the SD card and Linux runs normally. The HPS Ethernet throughput with the corrected design matches the published figure for the design (1.35 Gbit/s TCP transmit at MTU 1500).What are the issues in Nios® V processor for designs targeting Agilex® 27 FPGA device?
Description Due to a problem in the Quartus ® Prime Pro Edition software version 26.3, Nios® V Debug IP fails to execute dmcontrol.hartreset on a halted Nios® V processor. This is because there is a bug in Nios® V/c processor, when servicing dmcontrol.hartreset request while halted. If the processor is a running state, dmcontrol.hartreset can be executed successfully. Resolution To work around this problem in the Quartus ® Prime Pro Edition software version 26.3 (select one), Use dmcontrol.ndmreset to reset the processor at any states. Use dmcontrol.hartreset only when the processor is at running state. This problem is currently scheduled to be resolved in a future release of the Quartus ® Prime Pro Edition Software.Why does the EMIF Debug Toolkit report fixed channel 1 driver margin values for two channel memory designs?
Description Due to a problem in the Quartus® Prime Pro Edition Software version 26.1.1 and earlier, EMIF Debug Toolkit might report the same fixed driver margin values for every DQ pin of channel 1 when used with 2chx16 memory designs targeting Agilex® 3, Agilex® 5, and Agilex® 7 FPGA M-Series devices. The same behavior might also occur during Vref margining. Resolution Only the displayed values are affected. It does not impact the functionality of the hardware interface. This problem is scheduled to be fixed in a future release of the Quartus® Prime Pro Edition Software.