Quartus 20.1 crashes with VQM from synplify pro 2020.03

[AEsqu]

Quartus 20.1 crashes with VQM from synplify pro 2020.03 (old mapper, new Intel mapper fails at synplify side for another reason)

Problem Details

Error:

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?

Stack Trace:

 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)

End-trace

Executable: quartus

Comment:

None

System Information

Platform: linux64

OS name: Red Hat

OS version: 6

Quartus Prime Information

Address bits: 64

Version: 20.1.0

Build: 177

Edition: Pro Edition

[KhaiChein_Y_Intel]

Hi,

Can you share the design.qar for investigation?

Thanks.

Best regards,

KhaiY

[KhaiChein_Y_Intel]

Hi,

Do you have any updates?

Thanks.

Best regards,

KhaiY

[AEsqu]

Hi Khaiy,

I cannot provide our design.

Sorry about this.

[KhaiChein_Y_Intel]

Hi,

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?

Thanks.

Best regards,

KhaiY

[AEsqu]

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?

[KhaiChein_Y_Intel]

Hi,

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.

Thanks.

Best regards,

KhaiY

[AEsqu]

Hi,

Changing the indicated option in the picture from normal to off solves the Quartus crash..

[KhaiChein_Y_Intel]

Hi,

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.

Best regards,

KhaiY

[AEsqu]

A second option had to be set to off to avoid a crash too.

See the new picture.

[AEsqu]

And another one ...

[ebuteau]

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).