Why 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 countWhy do I get the error “‘clGetProfileDataDeviceIntelFPGA’ was not declared in this scope” when compiling OpenCL host code?
Description The library function clGetProfileDataDeviceIntelFPGA must be called in the host code when dynamically profiling an autorun kernel. If this function is called directly, the host code compilation may fail with an error like the ones below. Linux (gcc) error: ‘clGetProfileDataDeviceIntelFPGA’ was not declared in this scope Windows (Microsoft Visual Studio) error: unresolved external symbol clGetProfileDataDeviceIntelFPGA If the system is using the ICD driver, non-standard functions such as *IntelFPGA functions cannot be used directly. The OpenCL call clGetExtensionFunctionAddress must be used to get a function pointer for the non-standard function and that pointer must be used to call it. Resolution Using the prototype of the function, located in CL/ext.h extern CL_API_ENTRY cl_int CL_API_CALL clGetProfileDataDeviceIntelFPGA( cl_device_id /*device_id*/, cl_program /*program*/, cl_bool /*read_enqueue_kernels*/, cl_bool /*read_auto_enqueued*/, cl_bool /*clear_counters_after_readback*/, size_t /*param_value_size*/, void * /*param_value*/, size_t * /*param_value_size_ret*/, cl_int * /*errcode_ret*/ ); Replace the function call cl_int status = clGetProfileDataDeviceIntelFPGA (device, program, false, true, false, 0, NULL, NULL, NULL); with code using the syntax below cl_int (*get_profile_fn)(cl_device_id, cl_program, cl_bool,cl_bool,cl_bool,size_t, void *,size_t *,cl_int *); get_profile_fn = (cl_int (*) (cl_device_id, cl_program, cl_bool,cl_bool,cl_bool,size_t, void *,size_t *,cl_int *))clGetExtensionFunctionAddress("clGetProfileDataDeviceIntelFPGA"); cl_int status = (cl_int)(*get_profile_fn) (device, program, false, true, false, 0, NULL, NULL, NULL);Can I connect VCCIO of I/O bank 1 to 2.5 V for AS configuration with EPCQ or EPCQA device when using Cyclone® III, Cyclone® IV, or Intel® Cyclone® 10 LP device?
Description No, when you use EPCQ or EPCQA quad-serial configuration device for AS configuration, you cannot connect VCCIO of I/O bank 1 to 2.5 V in Cyclone® III, Cyclone® IV, or Intel® Cyclone® 10 LP device. This is because the minimum VOH of the FPGA is insufficient for driving EPCQ or EPCQA input pins. Resolution Use 3.0 V or 3.3 V for Bank 1 VCCIO in Cyclone III, Cyclone IV, and Intel Cyclone 10 LP devices when AS configuration with EPCQ or EPCQA devices is used.Why do I get a Fatal Error in Assembler when having ALTLVDS TX with a design?
Description You may see this error in the Quartus® Prime Software Standard version 17.0 or earlier. This error is due to either LVDS data output port “tx_out[*]” or external clock port “tx_outclock” of ALTLVDS TX IP is not assigned to LVDS I/O standard. Resolution To work around this problem, you should assign both the data output port and external clock output to the LVDS I/O standard.Creating OTN_cascade or SDI_cascade Instances at a Low or Medium IP Bandwith Causes the Arria® 10 and Cyclone® 10 GX fPLL or ATX PLL IP Parameter Editor GUI to Encounter an Error Related to f_max_pfd
Description If you set the fPLL or ATX PLL IP bandwidth to low or medium for Arria® 10 and Cyclone® 10 GX devices while attempting to create OTN_cascade or SDI_cascade instances, the IP Parameter GUI might display an error that relates to f_max_pfd. This issue affects the Quartus® Prime Standard Edition Software and the Quartus® Prime Pro Edition Software. Resolution In the fPLL or ATX PLL IP Parameter Editor, you cannot select the bandwidth after you select the OTN or SDI protocol. Therefore, before you create OTN_cascade or SDI_cascade instances, first select Basic from the Protocol mode pull-down menu and then select High from the Bandwith pull-down menu.Why does the Intel® FPGA Download Cable II driver installation fail on Windows* operating system?
Description Due to the expiration of the digital signature certificate of the Intel® FPGA Download Cable II driver for Windows* operating system, the installation process of the driver may fail. Follow the next steps to verify if the digital signature certificate of your driver has expired: Go to '<Quartus Installation Path>\qprogrammer\quartus\drivers\usb-blaster-ii' folder Right click on 'usbblasterii.cat' and select 'Properties', then select the 'Digital Signatures' tab Select the 'IFDLII Production Key1' signature from the 'Signature List' and click 'Details' Click on 'View Certificate' If the driver has expired, you will see the 'This certificate has expired or is not yet valid' message Resolution To work around this problem, follow the next steps: Download an updated version of the driver from the following link Decompress the downloaded file and substitute 'usb-blaster-ii.inf' and 'usb-blaster-ii.cat' files in '<Quartus Installation Path>\qprogrammer\quartus\drivers\usb-blaster-ii' folder Launch the Windows* 'Device Manager' Locate 'Altera USB-Blaster II (JTAG interface)' node under 'JTAG cables' in the Windows* 'Device Manager', right click and select 'Update Driver' Choose ´'Browse my computer for driver software' then click on 'Search for drivers in this location' and point to the new 'usb-blaster-ii.inf' file This problem is fixed starting with the Intel® Quartus® Prime Pro Edition software version 21.1.
