Quartus Prime software (18.1) quit unexpectedly

[mtrovato1]

Dear Sir/Madame,

When building a project in quartus 2018.1 the GUI stops (32% of the fitter progress) and the message in the subject pops up. The report is below. Do you have any idea of what can be the root of the problem or what I can check to shed some more light?

Please let me know what you think or if you need more info

Thanks

Best,

Marco

[1]

Problem Details
Error:
Internal Error: Sub-system: VPR20KMAIN, File: /quartus/fitter/vpr20k/apl/pcl_apl_node.cpp, Line: 4148

Internal Error

Stack Trace:

   0x85a1f0: PCL::APL::APLHandler::getFilterForPreviousClustersUsingUniqueRegions + 0xbd0 (fitter_vpr20kmain)

   0x85b538: PCL::APL::APLHandler::setPCLRun + 0x1128 (fitter_vpr20kmain)

   0x85dc3e: PCL::APL::APLHandler::cluster + 0xee (fitter_vpr20kmain)

   0x799fa1: APL::cluster + 0xe1 (fitter_vpr20kmain)

   0x2690d6: do_analytical_placement + 0xa56 (fitter_vpr20kmain)

   0x268650: do_analytical_placement_phase + 0x7f0 (fitter_vpr20kmain)

    0x3e4f6: l_do_ble_analytical_placement + 0x46 (fitter_vpr20kmain)

    0x3ea76: cl_build_cluster_of_block_from_scratch + 0x306 (fitter_vpr20kmain)

    0x34822: do_clustering + 0x552 (fitter_vpr20kmain)

    0x72c99: cl_flow_pack_to_cbes_2 + 0x909 (fitter_vpr20kmain)

    0x72296: cl_flow_pack_to_cbes + 0x96 (fitter_vpr20kmain)

   0x26c17c: l_do_clustering_phase + 0x18c (fitter_vpr20kmain)

   0x26b4c4: aa_flow_place + 0x64 (fitter_vpr20kmain)

   0x57380f: VPR_QI_FACADE::place_internal + 0x1f (fitter_vpr20kmain)

    0x2c766: FDRGN_EXPERT::run_vpr + 0x196 (fitter_fdrgn)

    0x2843b: FDRGN_EXPERT::place + 0x3b (fitter_fdrgn)

    0x143ab: fit2_fit_place_auto + 0x20b (comp_fit2)

    0x161e2: TclNRRunCallbacks + 0x62 (tcl86)

     0x3c4a: fit2_fit_place + 0x2fa (comp_fit2)

    0x161e2: TclNRRunCallbacks + 0x62 (tcl86)

    0x17a65: TclEvalEx + 0xa65 (tcl86)

    0xa6f8b: Tcl_FSEvalFileEx + 0x22b (tcl86)

    0xa5646: Tcl_EvalFile + 0x36 (tcl86)

    0x12606: qexe_evaluate_tcl_script + 0x376 (comp_qexe)

    0x11864: qexe_do_tcl + 0x334 (comp_qexe)

    0x16755: qexe_run_tcl_option + 0x585 (comp_qexe)

    0x380c3: qcu_run_tcl_option + 0x1003 (comp_qcu)

    0x160aa: qexe_run + 0x39a (comp_qexe)

    0x16e51: qexe_standard_main + 0xc1 (comp_qexe)

     0x2233: qfit2_main + 0x73 (quartus_fit)

    0x12e98: msg_main_thread + 0x18 (CCL_MSG)

    0x1467e: msg_thread_wrapper + 0x6e (CCL_MSG)

    0x16660: mem_thread_wrapper + 0x70 (ccl_mem)

    0x12761: msg_exe_main + 0xa1 (CCL_MSG)

     0x287e: __tmainCRTStartup + 0x10e (quartus_fit)

    0x17613: BaseThreadInitThunk + 0x13 (KERNEL32)

    0x526a0: RtlUserThreadStart + 0x20 (ntdll)

End-trace

Executable: quartus_fit
Comment:
None

System Information
Platform: windows64
OS name: Windows 10
OS version: 10.0

Quartus Prime Information
Address bits: 64
Version: 18.1.0
Build: 625
Edition: Standard Edition

[RichardTanSY_Intel]

I could not find this internal error in the database. Could you help to share your design .qar file (Project> Achieve Project) that could duplicate this error?

We will need to duplicate the error as without the error duplication from our side, it would be hard to find a workaround/solution.

Prior that, try to upgrade/migrate the design to the latest Quartus Standard version 22.1 to check if the issue persists, as a lot of bug has been fixed since then.

Best Regards,

Richard Tan

p/s: If you find any answers from the community or Intel Support to be helpful, we encourage you to mark them as the best answer or rate them 4/5 in the survey. 

[RichardTanSY_Intel]

Dropping a note to ask if my last reply was helpful to you?

Do you see the issue reoccur with Quartus version 22.1?

Best Regards,

Richard Tan

[mtrovato1]

Hello Richard,

sorry for the delayed reply, I took few days off at work. 

Upgrading to 22.1 would be a lot of work and probably not worth the effort. We are only reorganizing the source file structure from one old project to the new one. The old project (same sources) compiles w/o any problems.

I need a couple of hours in order to share the .qar file. Please confirm that you will still need it, even though I am not able to migrate to 22.1

Thanks

Best,

Marco

[mtrovato1]

Hello RIchard,

please find the .qar in attachment

Please let me know what you uncover.

Thanks and Best,

Marco

[RichardTanSY_Intel]

I have sent you an .INI file via email last week.

Could you try to use the .INI file and see if it able to solve the internal error?

By the way, I can't compile the design as it is missing a lot of Qsys components. I believe these are all your custom IP. Could you please confirm if the .qar file is able to compile?

Best Regards,

Richard Tan

[mtrovato1]

Hello RIchard,

I have not received the .INI file. Could you attach it here or upload it somewhere so I can download it? You can also try sending the email again.

Correct about the qsys. Please let me know if I can do anything to provide an archive project that can be compiled

Best,

Marco

[mtrovato1]

Hello Richard,

I have tarred the whole project. Can you untar and try to compile it?

Thanks

Marco

[RichardTanSY_Intel]

I have zip the .INI file and attach it here.

Here are the steps to follow:

1. Go to the project directory, which is the same directory where the .qpf file is located.
2. Paste the quartus.ini file in this directory.
3. Relaunch Quartus.

Please note that the attached document is strictly private and personal to its recipient.

Best Regards,

Richard Tan

[mtrovato1]

Hello Richard,

many thanks for the quartus.ini file, I am now able to build the project.

May I ask you more details about the lsc...checker=off line? Can you point to the documentation describing that? I have looked in a number of documents but I have had no luck.

Best,

Marco

[RichardTanSY_Intel]

It is a Quartus setting provided by the engineering team to workaround this specific internal error. This setting is not documented as users are not expected to make any configuration changes related to it.

Best Regards,

Richard Tan

[mtrovato1]

Thanks for your answers.

However, without knowing the root cause of the problem I am hesitant to trust the .sof file. Have you attempted to compile the shared .tgz file to dig a little bit further

Best,

Marco

[RichardTanSY_Intel]

Wait a sec, I have found in the database that the design reviewed is indeed the same as yours. It was filed in the IPS case back in 2019. Does that ring a bell? It seems that some information may have been lost or overlooked over time. 

Regarding what the issue was, I quoting what the engineering saying directly:

"When the clustering is computing utilization on a converged clustering solution, it sees a 99.64% utilization on the full chip. This is less than 100%, so there should be no over-utilization; However, the code assume that anything < 1.0 (eps=0.01) as the rule to filter out over-utilization regions, so that means any regions with >99% utilization counts as overflow and lead to bad things downstream. "

Last time, the engineering team confirmed that this issue does not exist in the Quartus Pro v19.1. Therefore, you may consider upgrading your design to Pro, which will provide you with peace of mind.

Best Regards,

Richard Tan

[mtrovato1]

Post erased

[mtrovato1]

Hello Richard,

after talking to my colleagues I have additional questions.

When you say 99.64% utilization do you mean that you actually compiled the project that I shared with you and you see that amount of CPU utilization? If so, I would like to share with you the original design that does not need the quartus.ini patch and kindly ask you to compile that too so you can tell me the peak utilization that you see.

Moreover, who was the person who contacted you in 2019 for this design? Do you have a pointer for that? Knowing that would help follow up on that.

Unfortunately I do not have the green light to upgrade to 19.1

Thanks

Marco

[RichardTanSY_Intel · Accepted solution]

The "99.64% utilization..." statement was based on the 2019 design.

The person who contacted Intel at that time was named Nathanael Huffman.

I have also attached the 2019 design for your reference.

Based on this information, my takeaway point is that the .INI file, provided in my previous reply, is derived from the 2019 design and should be safe to use in your current project. It has previously been verified by the engineering team in 2019.

Best Regards,

Richard Tan

[RichardTanSY_Intel]

Thank you for acknowledging the solution provided.

I'm glad to hear that your question has been addressed. Now, I will transition this thread to community support. If you have any further questions or concerns, please don't hesitate to reach out.

Thank you and have a great day!

Best Regards,

Richard Tan