Why does the SD/eMMC U-Boot driver fail to select the SDR12 mode for Agilex® 5 FPGA and Agilex® 3 FPGA devices in release 25.3.1 release and before?
Description Due to a problem in the U-Boot SD/eMMC driver in Agilex® 5 FPGA and Agilex® 3 FPGA devices in release 25.3.1 and before, U-Boot fails to select the SD SDR12 mode regardless of using the sd-uhs-sdr12 parameter in the device tree. The reason behind this problem is that the driver tries the SD_HS (50 MHz) mode first, so if this succeeds, then the SDR12 (25 MHz) is not tried. Because of this problem, currently, there is no direct method to force the driver to choose SDR12 mode. Resolution To workaround this problem, you need to use the following configuration in the device tree along with the SD/eMMC driver source code modification: 1. U-Boot device tree configuration: Remove no-1-8-v: Allows the MMC stack to perform voltage switching to 1.8V, which is required for UHS modes Remove cap-sd-highspeed: Ensures SDR12 becomes the highest priority mode available Add sd-uhs-sdr12: Explicitly declares SDR12 support &mmc { status = "okay"; no-mmc; disable-wp; //no-1-8-v; // Remove or keep commented out //cap-sd-highspeed; // Remove or keep commented out sd-uhs-sdr12; // Add this property vmmc-supply = <&sd_emmc_power>; vqmmc-supply = <&sd_io_1v8_reg>; max-frequency = <200000000>; sdhci-caps = <0x00000000 0x0000c800>; sdhci-caps-mask = <0x00002007 0x0000ff00>; // ... (rest of PHY timing configuration remains unchanged) }; 2. Modify the U-Boot drivers/mmc/sdhci-cadence.c source code as follows: You must update the host->quirks parameter to disable the SD High Speed mode at the driver level, providing an additional safeguard to ensure SDR12 is selected. static int sdhci_cdns_probe(struct udevice *dev) { : host->quirks |= SDHCI_QUIRK_WAIT_SEND_CMD; host->quirks |= SDHCI_QUIRK_BROKEN_HISPD_MODE; // Add this line : } This problem will be fixed in a future release.
Generation of AOCL Report Failed with below error
Description Due to a problem in the FPGA Support Package for the oneAPI DCP++/C++ Compiler version 2024.2, you might see this error. Generation of AOCL Report Failed with the below error PLEASE submit a bug report to https://software.intel.com/en-us/support/priority-support and include the Stack dump: … aocl-opt 0x0000XXXXXXXXXXXX llvm::AccessGroupInfo::hasIndependentAGsOrSafelen(llvm::Loop*, llvm::Instruction*, llvm::Instruction*, int&) + 195 … or … aocl-opt: XXXXXXXX: llvm::Value::~Value(): Assertion `materialized_use_empty() && "Uses remain when a value is destroyed!"' failed. … Resolution To work around this problem, download and install the 2024.2.1 patch for the FPGA Support Package below. Determine where the 2024.2 Intel oneAPI DCP++/C++ Compiler is installed. The FPGA Support Package will be located inside of the compiler installation directory in the ‘oclfpga’ folder. For Linux, this will be ‘<install-dir>/intel/oneapi/compiler/2024.2/opt/oclfpga’, where <install-dir> is typically either ‘/opt’ or ‘~’. For Windows, this will usually be ‘C:\Program Files (x86)\Intel\oneAPI\compiler\2024.2\opt\oclfpga’. Rename the existing ‘oclfpga’ directory to something else, e.g., ‘oclfpga.bak’ or ‘oclfpga.prev’. Unpack the given archive, .tar.gz for Linux and .zip for Windows, to extract the ‘oclfpga’ folder and place it in ‘intel/oneapi/compiler/2024.2/opt’. (Optional) Remove the backup folder created in Step ‘2’ after testing. This problem is scheduled to be fixed in a future release of the FPGA Support Package for the oneAPI DCP++/C++ Compiler.Why does marginal degradation of 1.8V VIL I/O standard occur on Stratix® 10 FPGAs and Agilex™ FPGAs family SDM I/O pins after long-term operation?
Description On all Stratix® 10 FPGA and Agilex™ FPGA devices, when the board MSEL is set to JTAG but Quartus® Prime design software is configured to AS or AVST×8, and SDM I/O pins are left unconnected (NC), long-term operation may cause the 1.8V VIL on those SDM I/O pins to degrade below the datasheet specification of 0.5985V (0.35 × 1.71V). Refer to device datasheet under Single-Ended I/O Standards Specifications section for SDM IO I/O standard specification. The degradation can lead to configuration issues. Resolution Select AVST×16 as the configuration scheme in Quartus when using JTAG MSEL with all SDM I/O pins left unconnected. AVST×16 does not use any SDM I/O pins, preventing the degradation. Refer to Configuration User Guide for the steps to enable dual-purpose pins when setting AVSTx16 mode in Quartus. Starting in Quartus® Prime Pro edition software version 26.1, a note will be updated in the Configuration User Guide and the tooltips for the Configuration scheme category under Device and Pin Options in Quartus.Why does GD55LB02GE QSPI flash fail in Linux* in FPGA SoC device?
Description If you use Linux* version between socfpga-6.0 and socfpga-6.12.43-lts with GD55LB02GE QSPI flash, you may fail to mount the file system in Linux if it’s stored in GD55LB02GE. This is caused by the gigadevice.c in these versions. Resolution This issue is fixed in socfpga-6.12.43-lts and afterwards. You can upgrade Linux source code to this version, or comment out the GD55LB02GE entry in gigadevice.c in old versions.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™ 3FPGA 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. 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 the Timing Analyzer report an unconstrained clock on the internal state signal when using the Generic Serial Flash Interface IP?
Description Due to a problem in the Quartus® Prime Pro Edition Software version 25.1.1 and earlier, you might see that the Timing Analyzer report an unconstrained clock on the internal state signal below, when using the Generic Serial Flash Interface (GSFI) IP. <instance_path>|intel_generic_serial_flash_interface_top_0|serial_flash_inf_cmd_gen_inst|state[0] Adding a create_generated_clock constraint removes the unconstrained clock report but introduces setup timing violations because the clock relationship is inferred as zero, making timing closure unachievable in Quartus® Prime Pro Edition Software version 25.1.1. Resolution There is no reliable SDC-based workaround to achieves timing closure; adding create_generated_clock can lead to setup violations due to a zero clock relationship. This problem is fixed beginning with the Quartus® Prime Pro Edition Software version 25.3.Why does downloading ELF file into Nios® V/g processor fail when disabled branch prediction, while enabled instruction cache?
Description Due to a problem in the Quartus ® Prime Pro Edition Software version 25.3.1, downloading ELF file into Nios ® V/g processor might fail when both the conditions below are fulfilled. Branch prediction is disabled, and Instruction cache is enabled The niosv-download command returns the error message below. Unexpected vCont reply in non-stop mode: E30 ERROR: GDB failed. This is because there is an RTL bug in the instruction cache related to its reset state. Resolution To work around this problem in the Quartus ® Prime Pro Edition Software version 25.3.1, Either enable branch prediction, Or disable instruction cache This problem is scheduled to be fixed in a future release of the Quartus ® Prime Pro Edition Software version 26.1.Why is there a failure in the design if we are doing design migration for Agilex™ 3/Agilex™ 5 FPGA, with GTS Reset Sequencer from version 25.3 to 25.3.1?
Description Following an IP upgrade from version 25.3 to version 25.3.1 of the Quartus® Prime Pro Edition software, there is a port renaming involved for Agilex™ 3 FPGAS or Agilex™ 5 FPGA GTS Reset Sequencer IP. There are two ports that has been renamed for improvement purpose. Resolution For a workaround, you need to update the existing port name to the new ports that are available in the GTS Reset Sequencer IP. The existing ports that will require update are: i_src_rs_refclk_status_bus_out (25.3) --> i_src_rs_refclk_status_bus (25.3.1) o_src_rs_refclk_status_bus_in (25.3) --> o_src_rs_refclk_status_bus (25.3.1)Why is there a fitter failure when using reference clock from HVIO System PLL for FABRIC_USE_CASE in the Agilex™ 3/ Agilex™ 5 FPGA GTS System PLL Clocks IP?
Description Due to a problem in the Quartus® Prime Pro Edition software version 25.3.1 and earlier, user will encounter fitter failure when they are using HVIO Reference Clock for Fabric_Use_Case. Resolution For a workaround, you need to set location assignment based on your selected devices in QSF assignment: Agilex™ 5 Family and Series Density Device Group Package Code Location Assignment A5E 013 A/B B23A/B32A/ M16A For Bank: 1A [SMHSSIPLLWRAP_X0_Y7_N1956] A5E 028 A/B B23A/B23A/ M16A For Bank: 1A [SMHSSIPLLWRAP_X0_Y7_N1956] 1B [SMHSSIPLLWRAP_X0_Y54_N1956] 4A [SMHSSIPLLWRAP_X121_Y7_N1956] A5E 065 A/B B23A/B32A 1A: [SMHSSIPLLWRAP_X121_Y7_N1956] 1B: [SMHSSIPLLWRAP_X0_Y54_N1956] 1C: [SMHSSIPLLWRAP_X0_Y101_N1956] 4A: [SMHSSIPLLWRAP_X185_Y7_N1956] 4B [SMHSSIPLLWRAP_X185_Y54_N1956] 4C [SMHSSIPLLWRAP_X185_Y101_N1956] A5D 064 A/B B32A 1A [SMHSSIPLLWRAP_X0_Y7_N2406] 1B [SMHSSIPLLWRAP_X0_Y15_N2406] 1C [SMHSSIPLLWRAP_X0_Y99_N2406] 1D [SMHSSIPLLWRAP_X0_Y107_N2406] 4A [SMHSSIPLLWRAP_X159_Y7_N2406] 4B [SMHSSIPLLWRAP_X159_Y15_N2406] 4C [SMHSSIPLLWRAP_X159_Y99_N2406] 4D [SMHSSIPLLWRAP_X159_Y107_N2406] This problem is scheduled to be fixed in a future release of the Quartus® Prime Pro Edition software.Why is there "sopcinfo2swinfo.exe: command not found" when running sopc-create-header-files under WSL, or Docker under Windows?
Description An error message like this: sopc-create-header-files: line 182: sopcinfo2swinfo.exe: command not found sopc-create-header-files: sopcinfo2swinfo.exe --input=./peripheral_subsys.sopcinfo --output=/tmp/sopc-create-header-files.1312.tmp.swinfo failed will be seen in the Quartus ® Prime Pro Edition Software version 25.3.1 and earlier, when using the sopc-create-header-files script within the Linux version of the Quartus ® Prime Pro Edition Software, running on the Microsoft* Windows operating system. The Linux version of the tools can be installed under Windows* using WSL, WSL2 or Docker. In all of these cases, the sopc-create-header-files script detects that it is running under Windows* and looks for an internal tool with the suffix “.exe”. However, since the Linux version has been installed, the tool does not have that suffix and so cannot be found by the sopc-create-header-files script. Resolution To work around the problem, either switch to using a Windows* installation of the Quartus® Prime Pro Edition Software, or follow these steps to continue using the Linux installation under Windows*: Under Linux, use the command “which sopc-create-header-files” to find the location of the script. Copy the script from this location to another location of your choice. Make the newly copied script version writable using the command: chmod +w <path to newly copied script> Modify your newly copied script version. Find the following line: windows_exe=.exe and either remove it or add a single # symbol at the start to comment it Use your newly modified version of the script instead of the installed version. This will now execute correctly.