Why does the ASMI Parallel II IP or the Generic Quad SPI Controller II IP fail to access a QSPI flash memory device?
Description Due to a problem in multiple Quartus® Prime Pro Edition and Standard Edition software versions, the ASMI Parallel II IP or the Generic Quad SPI Controller II IP fails to access a Quad SPI flash memory device. The affected software versions are: Quartus® Prime Pro Edition software versions from 22.1 to 25.3 Quartus® Prime Standard Edition software versions from 22.1 to 24.1 Chronologically, Prior to version 22.1, the initial state of DATA[3:2] was high. For the affected software versions, the initial state of DATA[3:2] was incorrectly changed to Hi-Z. For reader’s information, some quad SPI flash memory devices support RESET or HOLD function on DATA[3] and WRITE_PROTECT function on DATA[2]. DATA pins can be known as DATA, DQ, IO, or SIO across different QSPI flash memory device vendors. This modification to Hi-Z is recognized as low, thus the active-low RESET, HOLD and WRITE_PROTECT functions are enabled. With these, they prevent the flash controller IP from gaining access to flash devices. Resolution DATA[3:2] must be kept high as the initial state. If the targeted flash device is the Active Serial configuration flash memory, this problem is fixed starting from, Quartus® Prime Pro Edition software version 25.3.1, and Quartus® Prime Standard Edition software version 25.1. Otherwise (i.e. generic-purpose flash memory or affected software version), please refer to the workarounds below. For affected software versions, Targeted Flash Device Workarounds Active Serial configuration flash memory Differentiated with: DATA[3:2] pins are assigned to dedicated AS_DATA[3:2] pins Disable dedicated Active Serial interface option is turned off The initial state of DATA[3:2] is Hi-Z. Add external pull-up registers to the I/O VCC voltage on DATA[3:2]. Internal weak pull-up resistor option is unavailable for dedicated AS_DATA pins. Generic-purpose flash memory Differentiated with: DATA[3:2] pins are assigned to generic I/O pins Disable dedicated Active Serial interface option is turned on The initial state of DATA[3:2] is Hi-Z. Add external pull-up registers to the I/O VCC voltage on DATA[3:2], or Enable internal weak pull-up resistor on DATA[3:2] pins in Quartus® design project After Quartus® Prime Pro Edition software version 25.3.1 and Quartus® Prime Standard Edition software version 25.1, Targeted Flash Device Workarounds Active Serial configuration flash memory Differentiated with: DATA[3:2] pins are assigned to dedicated AS_DATA[3:2] pins Disable dedicated Active Serial interface option is turned off The initial state of DATA[3:2] is reverted to high. No workaround is needed. Generic-purpose flash memory Differentiated with: DATA[3:2] pins are assigned to generic I/O pins Disable dedicated Active Serial interface option is turned on The initial state of DATA[3:2] is Hi-Z. Add external pull-up registers to the I/O VCC voltage on DATA[3:2], or Enable internal weak pull-up resistor on DATA[3:2] pins in Quartus® design project Related IP Cores ASMI Parallel II IP, Generic Quad SPI Controller II IP
Why does Nios® V processor design fail to compile during Analysis & Synthesis when the QSYS file is added into the Quartus® Prime project instead of the QIP file?
Description In the Quartus ® Prime Standard Edition software version 25.1, any Nios ® V processor designs might fail to compile during Analysis & Synthesis when the QSYS file is added into the Quartus ® Prime project. Here are the possible error messages that you might receive: Error (10170): Verilog HDL syntax error at niosv_cpp_fsm.sv(1418) near text: "'"; expecting ":", or "?", or binary operator. Error (10355): SystemVerilog Enumeration Type Declaration error at riscv.pkg.sv(1163): encoded value for element "MXL32" has width 32, which does not match the width of the enumeration's base type (2) Error (10835): SystemVerilog error at riscv.pkg.sv(149): no support for unions Error (16950): Verilog HDL error at : decimal constant 00000000000000010000000000000000 is too large, using 1874919424 instead Error (16814): Verilog HDL error at ... : unknown literal value 00000000000000010000000000000000 for parameter ... ignored This is because the Quartus ® Prime Standard Edition software version 25.1 has been updated to adhere to the software requirements below. This requirement is not mandatory in prior versions of the Quartus ® Prime Standard Edition software. Resolution To work around this problem in the Quartus ® Prime Standard Edition Software version 25.1, Remove the QSYS file from the project using the Remove Files in Project function. Add the QIP file to the project using the Add Files in Project function. Related Articles ERROR building simple NIOS® V Compact project Nios® V Synthesis Fails with Quartus® Prime 25.1 LiteWhy does Ashling* RiscFree* IDE for Altera® FPGAs detect Core 0 only in a Nios® V processor multicore system?
Description Due to a problem in the Ashling* RiscFree* IDE for Altera software version 25.2.1 (version dated 9 th May 2025), the Ashling* RiscFree* IDE might fail to detect other Nios ® V processor cores (except Core 0) for Nios ® V processor multicore designs. This is because there is a bug in the Ashling* GDBServer software. Error message: [GDB server output] Error: The device configuration selected has only 1 core (Core 0). Core 1 is not available. Resolution To workaround this issue, please switch from Ashling* GDBServer to Open On-Chip Debugger (OpenOCD) when debugging a Nios ® V multicore processor system. Add the “–o" argument when running niosv-download. niosv-download app.elf -o <options> This problem is scheduled to be fixed, beginning with the Ashling* RiscFree* IDE for Altera software version 25.3.1 (version dated 1 st August 2025).Why does Ashling* RiscFree* IDE for Altera® FPGAs fail to debug a Nios® V processor C++ software project in Windows?
Description Due to a problem with the Ashling* RiscFree* IDE for Altera ® FPGAs software, debugging a Nios ® V processor software project may fail when it is written in the C++ language. This is because there is a bug in the processor toolchain from the Ashling* RiscFree* IDE for Altera ® FPGAs software. C projects are not affected by this issue. You might receive the following error messages. Error Messages How is RISC-V GDB executed? Error in services launch sequence: GDB prompt not read From Ashling* RiscFree* IDE for Altera software ../../../gdb/gdb/cp-name-parser.y:192: internal-error: fill_comp: Assertion ‘i’ failed. Executing riscv32-unknown-elf-gdb commands in the command-line interface The affected Ashling* RiscFree* IDE for Altera ® FPGAs software versions are: 24.3.1 (version dated 9 th Aug 2024) 24.4.0 (version dated 27 th Sep 2024) 25.1.1 (version dated 31 st Jan 2025) Note that: This problem only affects Windows environments. C projects are not affected by this problem. Resolution This problem is fixed beginning with the Ashling* RiscFree* IDE for Altera ® FPGAs software version 25.2.1 (version dated 9 th May 2025). You can download Ashling* RiscFree* IDE for Altera ® FPGAs software version 25.2.1 (version dated 9 th May 2025) separately from Quartus® Prime Pro Edition Installer for software version 25.1.1. Follow these steps: Go to the Quartus® Prime Pro Edition Installer for software version 25.1.1 download link. Select Windows as the Operating System. Download the Quartus® Prime Pro Edition Installer for software version 25.1.1. Launch the installation. Select the following files to install: Add-ons and Standalone Software > Ashling* RiscFree* IDE for Altera Add-ons and Standalone Software > Quartus ® Prime Pro Edition Programmer and Tools Note: Refrain from using the Quartus® Prime Pro Edition Installer for software version 25.3 to resolve this problem. The installer contains the older version of the Ashling* software (Software version 25.1.1).Why does Nios® V processor simulation fail when using the generated VHDL testbench from Platform Designer?
Description Due to a problem in the Quartus ® Prime Standard Edition software version 25.1, Nios ® V processor simulation may fail with the generated VHDL testbench system from Platform Designer for any processor design. This problem affects: All Altera ® FPGA device families in Quartus ® Prime Standard Edition software, and All Nios ® V processor variants (Nios ® V/g, Nios ® V/m, and Nios ® V/c processors). It is because the generation of the Nios ® V processor VHDL testbench system is not supported in Quartus ® Prime Standard Edition software version 25.1. Resolution To work around this problem in the Quartus ® Prime Standard Edition Software version 25.1, please select “Verilog” at the “Create testbench simulation model” input option. This problem is currently scheduled to be resolved in a future release of the Quartus ® Prime Standard Edition software. Related Articles 3.3.1. Preparing Hardware Design for SimulationWhy does a stack dump occur during an OpenCL™ kernel compile if the loop count exceeds the number of channels allocated?
Description A stack dump may occur during an OpenCL™ compile if a loop contains a write to an indexed channel and the loop count exceeds the number of channels allocated. See the example code below. channel unsigned char my_channel[16] __attribute__((depth(1024))); char data[32]; ... for (unsigned char i = 0; i < 32; i ) { write_channel_intel(my_channel[i], data[i]); } Resolution Be sure that the loop count never exceeds the number of channels allocated. #define num_channels 32 channel unsigned char my_channel[num_channels] __attribute__((depth(1024))); char data[num_channels]; ... for (unsigned char i = 0; i < num_channels; i ) { write_channel_intel(my_channel[i], data[i]); } This problem is fixed beginning with version 19.1 of the Intel® FPGA SDK for OpenCL™ compiler.How do I compile an OpenCL kernel using the latest version of the Intel® SDK for OpenCL™ with a Board Support Package (BSP) from a previous version?
Description Beginning with Intel® SDK for OpenCL™ and Intel Quartus Prime Pro version 18.1, it is possible to compile an OpenCL™ kernel using the latest version of the Intel® SDK for OpenCL™ while using a BSP compiled with a previous version. However, the Quartus Prime software version that matches the version of the BSP must also be installed and used . Resolution · Set environment variables to point the Quartus Prime version that was used to compile the BSP. · Set the environment variables to point to the BSP directory. · Set environment variables to point to the latest version of the Intel SDK for OpenCL. · Run the Intel® SDK for OpenCL™ initialization script. · Compile the kernel. · Run the design using the latest version of the Intel SDK for OpenCL or Intel RTE for OpenCL. For example, if you have a BSP from version 17.1, and you want to use the Intel® SDK for OpenCL™ version 18.1, you must have version 17.1 of the Quartus Prime software installed and you must set the environment variables as shown in the following scripts. Notes: Change the directories in the script to match your installation. Make sure there are no other versions of Quartus or the Intel® SDK for OpenCL™ in the path. Linux (mixed_compile.sh) # *** Set QUARTUS and QSYS 17.1 *** export QSYS_ROOTDIR=/IntelFPGA_pro/17.1/qsys/bin export QUARTUS_ROOTDIR=/IntelFPGA_pro/17.1/quartus/bin export QUARTUS_ROOTDIR_OVERRIDE=/IntelFPGA_pro/17.1/quartus/bin export PATH="/IntelFPGA_pro/17.1/quartus/bin/:$PATH" export PATH="/IntelFPGA_pro/17.1/qsys/bin:$PATH" # A10 ref BSP version 17.1 export AOCL_BOARD_PACKAGE_ROOT=/IntelFPGA_pro/17.1/hld/board/a10_ref export PATH="/IntelFPGA_pro/17.1/hld/board/a10_ref/ip/:$PATH" # set OpenCL version 18.1 export ALTERAOCLSDKROOT=/IntelFPGA_pro/18.1/hld export INTELFPGAOCLSDKROOT=/IntelFPGA_pro/18.1/hld #run the OpenCL Setup script in 18.1 source /IntelFPGA_pro/18.1/hld/init_opencl.sh Windows (mixed_compile.bat) rem *** Quartus and Qsys 17.1 *** set QSYS_ROOTDIR=c:\IntelFPGA_pro\17.1\qsys\bin set QUARTUS_ROOTDIR=c:\IntelFPGA_pro\17.1\quartus set QUARTUS_ROOTDIR_OVERRIDE=c:\IntelFPGA_pro\17.1%\quartus set path=%path%;c:\IntelFPGA_pro\17.1\quartus\bin64; set path=%path%;c:\IntelFPGA_pro\17.1\qsys\bin; rem *** A10 BSP 17.1 *** set AOCL_BOARD_PACKAGE_ROOT=c:\IntelFPGA_pro\17.1\hld\board\a10_ref set path=%path%;c:\IntelFPGA_pro\17.1\hld\board\a10_ref\ip; rem *** OpenCL SDK 18.1 *** set ALTERAOCLSDKROOT= c:\IntelFPGA_pro\18.1\hld set INTELFPGAOCLSDKROOT= c:\IntelFPGA_pro\18.1\hld %INTELFPGAOCLSDKROOT%\init_opencl.bat To verify the configuration is correct, run the following: (Linux) $cd /IntelFPGA_pro/18.1/hld/board/custom_platform_toolkit/tests/boardtest $aoc boardtest.cl (Windows) > cd c:\IntelFPGA_pro\17.1\hld\board\custom_platform_toolkit\tests\boardtest > aoc boardtest.cl If the configuration is correct, the following message should appear after compilation. aoc: Hardware generation completed successfully.Why do I get the error “CL_INVALID_ARG_SIZE” when using type long long as an OpenCL™ kernel argument in the host code?
Description If a signed or unsigned long long type is used in the OpenCL™ host code function clSetKernelArg() as shown below unsigned long long data = 1; clSetKernelArg(kernel, 0, sizeof(unsigned long long), (void*)&data); then an error like the following may occur when the host code is compiled using the Intel® SDK for OpenCL™. Context callback: Argument size is the wrong size ERROR: CL_INVALID_ARG_SIZE Location: host/src/main.cpp:91 Failed to set kernel arg 0 This error did not appear for this case in versions earlier than 18.1 of the Intel® SDK for OpenCL™. The error now appears because the size of an unsigned long long type was changed from 8 to 16 in the underlying kernel compiler, but the host call sizeof(unsigned long long) still returns 8. Types signed / unsigned long long do not have a defined size in C99 or OpenCL™ version 1.X so it's allowed for the host and device to use different sizes for the type. As such, one should never use it as the type of an argument to the kernel. It's not guaranteed to be portable between compilers, devices, or even compiler versions. In the OpenCL™ 2.0 specification, a long long type is defined as 128 bits, but the C99 ambiguity remains. The OpenCL™ specification does not add a cl_* compatibility type, so it is not possible to use a long long type as a scalar argument safely. Resolution The recommended workaround for this problem is to use an OpenCL™ defined type such as cl_ulong/unsigned long in your host/device code. Alternately, do not use the sizeof() call and force the size of the long long argument to be 16 bytes as shown below. clSetKernelArg(kernel, 0, 16, (void*)&data);Why do I get the error “Unable to determine the execution environment” when running the “aocl version” command in the Intel SDK for OpenCL?
Description Due to an issue in version 18.1.0 of the FPGA Runtime Environment for OpenCL™, the command “aocl version” will produce the following errors: aocl: Unable to determine the execution environment of the FPGA Runtime Environment for OpenCL(TM). aocl: Detailed error: Could not find SDK internal libraries directory /opt/intel/intelFPGA_pro/18.1/aclrte-linux64/linux64/lib aocl: Detailed error: Could not determine the path to SDK internal libraries Resolution The workaround is to run the following command to create the directory that the command is looking for. $ mkdir -p $INTELFPGAOCLSDKROOT/linux64/lib This problem is fixed beginning with the Quartus® Prime Software version18.1.1Why does my OpenCL kernel compilation fail to generate hardware even though the estimated resources are low?
Description If your OpenCL™ kernel fails to generate hardware even though the estimated resources are low, the failure may be due to excessive unrolling of loops that access global memory. Loops that access global memory should not be unrolled beyond where a read or write to global memory is wider than the memory interface in the BSP. This will cause contention, routing congestion and may result in compilation failure. Resolution The width of the external memory interfaces can be found in the board_spec.xml file in the OpenCL™ BSP. Here is an example from the board_spec.xml of the Arria 10 GX development kit BSP. (a10_ref) <!-- DDR4-2400 --> <global_mem name="DDR" max_bandwidth="19200" interleaved_bytes="1024" config_addr="0x018"> <interface name="board" port="kernel_mem0" type="slave" width="512" maxburst="16" address="0x00000000" size="0x80000000" latency="240"/> </global_mem> As you can see, the external memory interface width on this BSP is 512 bits. (width="512") Therefore, if a loop accesses global 32-bit integers, the loop should not be unrolled more than 16. (512 / 32 = 16) If the original loop count is not a multiple of 16: 1. Round up the new loop count to a multiple of 16. 2. Make any on-chip memories in the loop large enough to accommodate the new loop count 3. Use conditionals to prevent reads or writes when the new loop count exceeds the original loop count
