Why does a kernel panic occur when OpenCL™ Applications are executed on Intel® FPGA Development Kits with IOMMU support enabled?
Description When executing OpenCL™ host applications on an attached development kit while IOMMU (e.g. intel_iommu) is enabled in a Linux Kernel, a kernel panic may occur and cause the host to hang. This may happen even if 'aocl diagnose' and 'aocl program' pass. The hang occurs because the OpenCL™ board support packages (BSPs) for the development kits don't support SR-IOV. Resolution To work around this problem, disable IOMMU functionality : For example on CentOS7.4, with grub2, UEFI and intel_iommu : 1. Edit /etc/default/grub and delete the following line. intel_iommu=on in GRUB_CMDLINE_LINUX 2. Update grub configuration file grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg 3. Reboot 4. Check /proc/cmdline Ensure intel_iommu=on does not appear on the kernel command line. This workaround does not apply to the Intel FPGA Programmable Acceleration Card (PAC) since that OpenCL™ BSP does support SR-IOV. If IOMMU is disabled when using the PAC, refer to the Intel® Acceleration Stack Quick Start Guide for instructions to enable the Intel IOMMU driver.error: Unexpected use of HDL library function(s) (possibly due to taking the address of the function)!
Description You may see this error message when the Intel® FPGA SDK for OpenCL™ compiler executes an EFI(Extensible Firmware Interface) function which is equivalent to its OpenCL funtion Resolution This problem is fixed beginning with the Intel FPGA SDK for OpenCL compiler software version 18.1.Why does aocl diagnose fail while using Windows 10?
Description When using Windows® 10, aocl diagnose may fail even though the board is installed in the PC and the user has installed the drivers using aocl install. If the user has installed the drivers then opens Windows Device Manager, the board should show up under "unknown device". Why does this happen? Windows 10 enforces driver signatures by default and the OpenCL drivers for our development kits are not "signed" for Windows 10. Resolution To work around this problem, run aocl uninstall then reboot the computer. After the computer has restarted, disable Windows 10 signed driver enforcement as shown below. Click the Start menu and select Settings. Click Update and Security. Click on Recovery. Click Restart now under Advanced Startup. (The computer won't actually restart until after step 8.) Click Troubleshoot. Click Advanced options. Click Startup Settings. Click on Restart. On the Startup Settings screen press 7 or F7 to disable driver signature enforcement. After the computer has finished booting up, run aocl install. Run aocl diagnose to verify that it succeeds Note: If your system has BitLocker enabled, you will need to enter the recovery key between steps 8 and 9 above. You must get the recovery key before starting the above procedure. To get the recovery key, do the following: Run Bitlocker Manager Select “Back up your Recovery Key” Select “Print the recovery key” This problem is scheduled to be fixed in a future version of Quartus.Error: "cannot find board_env.xml in ..."
Description When using Intel® FPGA OpenCL™ SDK 18.1, customer may get error information as "cannot find board_env.xml" during kernel compilation flow when a relative path is used to specify the -board-package parameter. For example: aoc -no-auto-migrate boardtest.cl -o boardtest_a10soc_noautomigrate/boardtest.aocx -board-package=./board/a10soc Resolution To work around this problem use an absolute path for the the board-package. aoc -no-auto-migrate boardtest.cl -o boardtest_a10soc_noautomigrate/boardtest.aocx -board-package=/<quartus installation>/hld/board/a10socWhy does #pragma ivdep not work correctly in aocl version 17.0?
Description In 16.1, this code behaved as expected where the outer loop was serialized due to dependencies and the inner loop dependencies were removed by the #pragma ivdep. // This loop gets serialized due to true dependencies with inner loop for (unsigned char x = 0; x < 4; x ) { // Inner loop does not have inter-iteration dependencies, but depends on outer loop #pragma ivdep for (unsigned char y = 0; y<64; y ) { In 17.0, the #pragma ivdep is now applied to both the inner and outer loop, so the dependencies in the outer loop are not accounted for by the compiler. As a result, similar code may not work correctly in hardware despite working in emulation. Resolution Workaround: 1. Add an extra argument "dummy" to the kernel. On the host side, always pass 1 for this dummy argument. BEFORE __kernel void my_kernel( __global cpx_t* restrict input, __global cpx_t* restrict result) AFTER __kernel void my_kernel( __global cpx_t* restrict input, __global cpx_t* restrict result, int dummy) 2. In the loop nest, wrap the inner loop in "if (dummy)": // This loop gets serialized due to true dependencies for (unsigned char x = 0; x < 4; x ) { if (dummy) { // No dependencies within each set of 64 iterations #pragma ivdep for (unsigned char y = 0; y<64; y ) { This issue is scheduled to be fixed in a future version of the Intel© OpenCL™ for FPGA SDK.Internal Compiler Error: Missing start cycle information for queried node: sync_out
Description You may see this error message when the Intel® FPGA SDK for OpenCL™ compiler executes an autorun kernel. OpenCL and the OpenCL logo are trademarks of Apple Inc. used by permission by Khronos. Resolution This problem is fixed beginning with the Intel FPGA SDK for OpenCL compiler software version 18.0.Why does my Altera Hard IP for PCI Express not enter compliance loopback in Gen 3 mode?
Description The Altera® Hard IP core for PCI® Express will not enter compliance loopback mode at Gen3 rates if the compliance receive bit in the configuration register space, has not been set by the loopback master. Resolution To comply with the PCI Express Specification, ensure your loopback master sets the compliance receive bit correctly. Related Articles Does IP Compiler for PCIe support automatic Compliance mode detection during Compliance Base Board (CBB) testing?Fatal Error: Read data comes back but dynamic OCT ctrl is not in read mode
Description You may see the following error when you simulate the UniPHY based DDR3 controller in full calibration mode. # ** Fatal: Read data comes back but dynamic OCT ctrl is not in read mode Resolution Open the following file in your simulation file-set: altdq_dqs2_ddio_3reg_<user_device>.sv Find the following line: (1, "Read data comes back but dynamic OCT ctrl is not in read mode"); Replace the line above with the following line: ("Read data comes back but dynamic OCT ctrl is not in read mode at time %f", ); The simulation should run without any errors once the above change is implemented.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.Error (178004): Could not find location for Clock Divider that enable routing of bonding clock lines
Description You may see the following Quartus® II Fitter error with Stratix® V GX and Arria® V GX devices if you attempt to place logical channel 0 of a bonded transceiver PHY IP on a transceiver channel that does not have access to a central clock divider block. "Error (178004): Could not find location for Clock Divider that enable routing of bonding clock lines" On Stratix V and Arria V transceiver devices, only physical channels 1 and 4 within a transceiver block can access a central clock divider. Resolution To work around this problem, assign logical channel 0 of the PHY IP to physical channel 1 or 4 of the transceiver bank. This information will be updated in a future version of the Altera Transceiver PHY IP Core User Guide. This limitation was removed in version 11.1.1 of the Quartus® II software.