Internal Error: Sub-system: CDB_SGATE, File: /quartus/db/cdb_sgate/cdb_sgate_component.cpp, Line: 926
Port direction does not agree.
0x5f4ac: CDB_SGATE_COMPONENT::retrieve_known_port + 0x3ba6c (db_cdb_sgate)
0x4b568: qis_get_component_ports + 0x118 (synth_qis)
0x4874a: QIS_RTL_STAGE::IMPL::merge_nodes + 0x64a (synth_qis)
0x49219: QIS_RTL_STAGE::IMPL::merge_sgate_models + 0x339 (synth_qis)
0x43a02: QIS_RTL_STAGE::IMPL::dissolve_partition + 0x412 (synth_qis)
0x53641: QIS_RTL_STAGE::IMPL::uniquify + 0x9b1 (synth_qis)
0x54778: QIS_RTL_STAGE::IMPL::uniquify + 0xc08 (synth_qis)
0x1bb98: qis_uniquify + 0x1f8 (synth_qis)
0x16442: TclNRRunCallbacks + 0x62 (tcl86)
0x17c4d: TclEvalEx + 0x9ed (tcl86)
0xa6a8b: Tcl_FSEvalFileEx + 0x22b (tcl86)
0xa5136: Tcl_EvalFile + 0x36 (tcl86)
0x14ebc: qexe_evaluate_tcl_script + 0x3fc (comp_qexe)
0x13f72: qexe_do_tcl + 0x4b2 (comp_qexe)
0x1a34e: qexe_run_tcl_option + 0x5ee (comp_qexe)
0x18195: QCU::DETAIL::intialise_qhd_and_run_qexe + 0x95 (comp_qcu)
0x290bc: qcu_run_tcl_option + 0x2ec (comp_qcu)
0x19c58: qexe_run + 0x438 (comp_qexe)
0x1ad8a: qexe_standard_main + 0x26a (comp_qexe)
0x34d9: qsyn2_main + 0x129 (quartus_syn)
0x14a08: msg_main_thread + 0x18 (CCL_MSG)
0x160ae: msg_thread_wrapper + 0x6e (CCL_MSG)
0x20fb0: mem_thread_wrapper + 0x70 (ccl_mem)
0x13f8d: msg_exe_main + 0x20d (CCL_MSG)
0x4dd4: __scrt_common_main_seh + 0x11c (quartus_syn)
0x17bd3: BaseThreadInitThunk + 0x13 (KERNEL32)
0x6cee0: RtlUserThreadStart + 0x20 (ntdll)
OS name: Windows 10
OS version: 10.0
Quartus Prime Information
Address bits: 64
Edition: Pro Edition
Cleaning the project didn't help.
As I want to evaluate the update from Cyclone V to Cyclone 10 GX it is a project generated with Quartus Prime 18.0, which I tried to migrate to Quartus Prime Pro 19.2.
IP Generation -> O.K.
Analysis & Synthesis runs fine until "Creating instance-specific data models and dissolving soft partitions" where it crashes.
It must be design-related because trying to compile a Cyclone 10GX example design worked without any problem.
I can provide you with the archived project, but not in the community.
yes, I received the email.
The problem is, that at the moment I do not have the simple test case, as the problem only occurs at one specific project.
I tried to build a simple project in Quartus Prime 18.0 and then do the migration to Quartus Prime 19.2. But no problem in this case.
Another problem is, that I could not archive the whole project, because it needs Analysis & Elaboration to know which files need to be archived and this is the point, where it fails.
Next step, I will try to find out, which specific part of the project causes Quartus to crash.
Maybe the cause is an IP, or something like that.
Can you tell me what is meant by "Port direction does not agree." in the reprt file?
Maybe this help to point me to the right direction.
It is difficult to find the root cause without the test case due to limited information in the error message.
It has something to do with a connection of a module where the port direction does not match the expected one. This is often related to connecting bidir (e.g. bidir to input or vice versa). Or possibly the size of the port doesn't match, or it is connecting a bus to a scalar. Or it could be that the component does not match the entity.
O.K. the problem was an old custom generated tristate component. It is part of a component which was generated long time ago in block editor, but as it is still working, it is still in use.
By the way I found out that in Quartus Prime Pro 19.2 it is no more possible to create a symbol out of an HDL-File, correct?
I know, that support of block and symbol-editor is getting lower and lower, but although I write the specific components in VHDL, I liked it to keep the top-level-design in blocks as in my opinion it is more clear.
Yes. It is no longer supported. You may open the RTL Viewer by clicking on Tools > Netlist Viewers > RTL Viewer. It seems like you found a root cause of this error. Could you provide a simple test case for error replication?
I received the feedback from the team today. Please see the feedback below.
The issue is that Tri8.bsf shows that tridata is of type bidir, but in Tri8.vhd, tridata is an output. You need to fix the design so that the Tri8 symbol used in TriTest.bdf matches the implementation of Tri8 in Tri8.vhd. Right now the Tri8 symbol says that tridata is a bidir but in Tri8.vhd tridata is an output. If you make the two match the design goes through.
You are encourage to move away from using bdf. It is much better to a modern language that is also used by other tools, i.e. Verilog, systemverilog or vhdl.
Thank you for your support.
Yes, in recent projects we use vhdl, but there are some bdf-relicts, where it is still possible to use them in current designs.
And as mentioned earlier, I liked to use the block-view for the top-level-entity to have a good overview and find the corresponding higher-level-code easier.
This internal error is scheduled to be fixed in the future release of the Intel Quartus Prime software by issueing an error message instead of internal error.
Have you tried to change the design so that the Tri8 symbol used in TriTest.bdf matches the implementation of Tri8 in Tri8.vhd.