Quartus 20.1 crashes with VQM from synplify pro 2020.03 (old mapper, new Intel mapper fails at synplify side for another reason)
Internal Error: Sub-system: CUT, File: /quartus/db/cut/cut_lcell_util.cpp, Line: 2646
Can't absorb these particular LUT input inversions on arith comb modes using this code path: should the more general case be used?
Quartus 0x544317: CUT_LCELL_UTIL::process_inverted_lut_inputs(CDB_ATOM_NODE*) + 0xb17 (db_cut)
Quartus 0x129808: FSAC_RP_UTIL_BODY::try_inverting_iterm_without_creating_inverter(CDB_ATOM_ITERM*) + 0x188 (fitter_fsac)
Quartus 0x129e6f: FSAC_RP_UTIL_BODY::sweep_removable_inverter_lut(CDB_ATOM_NODE*) + 0x60f (fitter_fsac)
Quartus 0x12a7de: FSAC_RP_UTIL_BODY::sweep_removable_inverter_luts(FSAC_RP_UTIL_BODY::TOUCHED_STATE) + 0xce (fitter_fsac)
Quartus 0x12c6f0: FSAC_RP_UTIL_BODY::sweep_all_stale_removable_wire_and_inverter_luts() + 0x40 (fitter_fsac)
Quartus 0x12c7d8: FSAC_RP_UTIL_BODY::~FSAC_RP_UTIL_BODY() + 0x68 (fitter_fsac)
Quartus 0x12cad5: FSAC_RP_UTIL::free_permanent_data() + 0x15 (fitter_fsac)
Quartus 0xbf67d: FDRGN_REGISTER_PACKER::do_packing(FITCC_ENV*) + 0x17d (fitter_fdrgn)
Quartus 0x7a02e: fdrgn_post_plan_ops(bool) + 0xc2e (fitter_fdrgn)
Quartus 0x266c0: fit2_fit_plan + 0x706 (comp_fit2)
Quartus 0x4c942: TclNRRunCallbacks + 0x42 (tcl8.6)
Quartus 0x4de7b: TclEvalEx + 0x68b (tcl8.6)
Quartus 0xf3f0e: Tcl_FSEvalFileEx + 0x25e (tcl8.6)
Quartus 0xf3ffe: Tcl_EvalFile + 0x2e (tcl8.6)
Quartus 0x1412e: qexe_evaluate_tcl_script(std::string const&) + 0x452 (comp_qexe)
Quartus 0x18541: qexe_do_tcl(QEXE_FRAMEWORK*, std::string const&, std::string const&, std::list<std::string, std::allocator<std::string> > const&, bool, bool) + 0x41b (comp_qexe)
Quartus 0x194fa: qexe_run_tcl_option(QEXE_FRAMEWORK*, char const*, std::list<std::string, std::allocator<std::string> >*, bool) + 0x559 (comp_qexe)
Quartus 0x39632: QCU::DETAIL::intialise_qhd_and_run_qexe(QCU_FRAMEWORK&, FIO_PATH const&, std::string const&, std::string const&, char const*, std::list<std::string, std::allocator<std::string> >*, bool) + 0xc5 (comp_qcu)
Quartus 0x439b9: qcu_run_tcl_option(QCU_FRAMEWORK*, char const*, std::list<std::string, std::allocator<std::string> >*, bool) + 0x225 (comp_qcu)
Quartus 0x1cfae: qexe_standard_main(QEXE_FRAMEWORK*, QEXE_OPTION_DEFINITION const**, int, char const**) + 0x7a0 (comp_qexe)
Quartus 0x403202: qfit2_main(int, char const**) + 0x92 (quartus_fit)
Quartus 0x3ebca: msg_main_thread(void*) + 0x10 (ccl_msg)
Quartus 0x40dd2: msg_thread_wrapper(void* (*)(void*), void*) + 0x64 (ccl_msg)
Quartus 0x14bde: mem_thread_wrapper(void* (*)(void*), void*) + 0x5e (ccl_mem)
Quartus 0xc7fa: err_thread_wrapper(void* (*)(void*), void*) + 0x1e (ccl_err)
Quartus 0x6c95: thr_thread_wrapper + 0x15 (ccl_thr)
Quartus 0x41927: msg_exe_main(int, char const**, int (*)(int, char const**)) + 0x148 (ccl_msg)
System 0x1ed1d: __libc_start_main + 0xfd (c)
Quartus 0x402ab5: (quartus_fit)
OS name: Red Hat
OS version: 6
Quartus Prime Information
Address bits: 64
Edition: Pro Edition
It is difficult to investigate the root cause without the design. I understand that you cannot share the full design. Is it possible to provide a simple test case for issue replication?
I could if the Intel crash report was a bit more precise,
it does not mention the instance/module that makes the crash.
Is it possible to enable an debugger log or so to figure out on which block of the VQM it fails?
Yes. There is limited information in the error message; this is the reason why a design is requried for me to send to engineering team for debugging. I think there is no command/settings for user to debug which block causes the error.
It is glad that you found the root cause and workaround. Thanks for updating the workaround in this forum thread so that other users who see this error in their design can work around it.
I now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.
Is there any update on an official fix for this bug. We have the same issue and we can not deactivate the timing optimization because it affects too much the performance.
We are using Quartus 20.1 with Synplify Premier 2020.03-SP1 on Linux64 (Ubuntu 20.04).