Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16556 Discussions

Error: Assert failure at RegNodeInsertion.cpp(854)

Altera_Forum
Honored Contributor II
1,294 Views

Hi, 

 

My design is made of NDRange kernels and runs correctly in emulation. 

However, I cannot generate the report as I get the "Error: Assert failure at RegNodeInsertion.cpp(854)". 

 

I have no idea where in the kernel to start looking for the error source as I do not understand the info the compiler provides. 

Any suggestion on how to solve this? 

 

******* Error: Assert failure at RegNodeInsertion.cpp(854) ******* Register: REG (0x16ca770): Basic block: Block44 0x1775430 Predecessors: 0x17b4970 Successors: 0x11b5b70 Value: Cycle: 277 ==> 277 Successor: BARRIER (0x11b5b70): Basic block: Block44 0x1775430 Predecessors: 0x17b4f00 0x1794430 0x11951d0 0x12bcfc0 0x12bd170 0x12bd320 0x12bd850 0x12bd9e0 0x12bec70 0x121f2d0 0x1222a80 0x16ca770 Successors: 0x17b5450 0x1198da0 0x17dcbf0 0x17dcd80 0x17dcf30 0x17dd0e0 0x17dd290 0x17dd440 0x17dd5f0 0x17dd7a0 0x17dd950 Instruction: Cycle: 279 ==> 280 Barrier variables: succ_start_cycle <= reg_end_cycle FAILED 0 libLLVM-3.0.so 0x00007f1e8b61197f 1 libLLVM-3.0.so 0x00007f1e8b6138f2 2 libpthread.so.0 0x00007f1e8a5daaf0 3 libLLVM-3.0.so 0x00007f1e8bb774cd acl::RegNodeInsertion::split_multi_tap_reg_node(acl::CCDFGNode*) + 1517 4 libLLVM-3.0.so 0x00007f1e8bb784a5 acl::RegNodeInsertion::split_multi_tap_reg_nodes() + 1173 5 libLLVM-3.0.so 0x00007f1e8b9909e6 acl::CapacityBalancePass::runOnFunction(llvm::Function&) + 3014 6 libLLVM-3.0.so 0x00007f1e8b732e0f llvm::FPPassManager::runOnFunction(llvm::Function&) + 527 7 libLLVM-3.0.so 0x00007f1e8b732f70 llvm::FPPassManager::runOnModule(llvm::Module&) + 80 8 libLLVM-3.0.so 0x00007f1e8b732931 llvm::MPPassManager::runOnModule(llvm::Module&) + 577 9 libLLVM-3.0.so 0x00007f1e8b732adb llvm::PassManagerImpl::run(llvm::Module&) + 187 10 aocl-llc 0x000000000040bdc0 main + 5360 11 libc.so.6 0x00007f1e8957100a __libc_start_main + 234 12 aocl-llc 0x00000000004098e9 Stack dump: 0. Program arguments: /opt/cad/altera/altera-16.0/hld/linux64/bin/aocl-llc -march=fpga -mattr=option3wrapper -fpga-const-cache=1 -board /home/wimi/lvs/BSP_AOC_GIDEL/Proc10A_16.0.2/hardware/Proc10A_X115/board_spec.xml -dbg-info-enabled calc_initpop.bc -o calc_initpop.v 1. Running pass 'Function Pass Manager' on module 'calc_initpop.bc'. 2. Running pass 'Loop Capacity Balance Pass' on function '@perform_ls' Error: Verilog generator FAILED. Refer to calc_initpop/calc_initpop.log for details.
0 Kudos
2 Replies
Altera_Forum
Honored Contributor II
478 Views

Hopefully someone comes along with a more in depth answer but when I've received weird error messages like this I typically comment parts of my kernel out until I can isolate the line(s) of code that cause the error. Once you know the code or code style that is causing issues you can typically refactor it to be more compiler friendly. 

 

Have you been able to successfully build NDRange kernels previously on this machine with this version of the tool?
0 Kudos
Altera_Forum
Honored Contributor II
478 Views

 

--- Quote Start ---  

Hopefully someone comes along with a more in depth answer but when I've received weird error messages like this I typically comment parts of my kernel out until I can isolate the line(s) of code that cause the error. Once you know the code or code style that is causing issues you can typically refactor it to be more compiler friendly. 

--- Quote End ---  

 

 

To be honest this is the best way to answer this question. 

 

When it comes to such compiler crashes, there is neither a fixed pattern to why it crashes crash, nor a fixed pattern as to how it can be fixed/avoided, and there are A LOT of such crashes. These problems should be fixed by Altera since nobody else has access to the compiler's source code, and you can always open a ticket with Altera and report the problem; however, by the time the issue is confirmed and then fixed (if they opt to fix it), it will probably take a couple of months which is not a viable waiting time for most people. At the end of the day, refactoring the code to bypass the crash is probably the fastest solution.
0 Kudos
Reply