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

Internal Error during Fitter (Place & Route) when compiling a PCIe x1 demo

Altera_Forum
Honored Contributor II
3,447 Views

Hello all, 

 

First time poster, thanks in advance for reading. 

 

I'm experiencing an Internal error during the Fitter (Place and Route) stage and it's 100% reproducible with no obvious workaround. Stack trace below. 

 

Environment is Quartus II 12.1sp1 on Windows 7 32bit. 

Using the Cyclone IV GX PCIe development kit DK-DEV-4CGX150N 

I've downloaded the associated GX iv software kit (cycloneIVGX_4cgx150_fpga_v12.1.0.exe). 

I'm attempting to compile the vanilla reference project 'c4gx_PCIe_gen1_x1' with zero changes. 

I've unpacking the c4gx_PCIe_gen1_x1.QAR multiple times and compiled with/without removing the incremental_db and db dirs, it always fails at the same Fitter stage. 

 

Another member posted the same stack trace (roughly 3 weeks ago) but it the post trailed off with no obvious conclusion than 'send the archive to a specific email address'. It wasn't clear whether he was using this project codebase or something completely different. 

 

Any help or advise would be welcome. 

 

Thanks, 

 

- Steve 

 

Internal Error: Sub-system: VPR20KMAIN, File: /quartus/fitter/vpr20k/altera_arch_common/altera_arch_wire_maps.c, Line: 1546 

Internal Error 

Stack Trace: 

0x1f6eec: _vpr_qi_jump_to_exit + 0x64 (fitter_vpr20kmain) 

0x2b9162: _aa_pl_global_create_initial_placement_hints + 0xad (fitter_vpr20kmain) 

0x2b919b: _vpr_exit_at_line + 0x37 (fitter_vpr20kmain) 

0x2323da: _handle_assertion_failure_stripped + 0x25 (fitter_vpr20kmain) 

0x1d172c: ___sse2_available_init + 0x82728 (fitter_vpr20kmain) 

0x20177: _Dinkum_std::vector<_Dinkum_std::set<int,_Dinkum_std::less<int>,MEM_STL_ALLOCATOR<int> >,MEM_STL_ALLOCATOR<_Dinkum_std::set<int,_Dinkum_std::less<int>,MEM_STL_ALLOCATOR<int> > > >::_Insert_n + 0x2a7 (fitter_vpr20kmain) 

0xf3838: _aa_rt_wire_maps_update_with_current_routing + 0x88 (fitter_vpr20kmain) 

0x17c3d: _aa_rt_update_wire_maps_update_after + 0x7d (fitter_vpr20kmain) 

0x2d2ff: _aa_rt_timing_tamer_has_router_converged + 0x32f (fitter_vpr20kmain) 

0x2b66c: _vpr_qi_thr_mutex_destroy + 0xfc (fitter_vpr20kmain) 

0x146d3: _aa_fsda_router_compute_pin_connection_delay_chain_groups + 0x83 (fitter_vpr20kmain) 

0x128ed4: _aa_route_alg_perform_timing_driven_route + 0x24 (fitter_vpr20kmain) 

0x11584a: _aa_route_try_route + 0x6a (fitter_vpr20kmain) 

0x110c5e: _Dinkum_std::vector<_Dinkum_std::_Hash<_Dinkum_std::_Hmap_traits<int,int,_Dinkum_std::hash_compare<int,_Dinkum_std::less<int> >,MEM_STL_ALLOCATOR<_Dinkum_std::pair<int,int> >,0> >::iterator,MEM_STL_ALLOCATOR<_Dinkum_std::_Hash<_Dinkum_std::_Hmap_traits<int,int,_Dinkum_std::hash_compare<int,_Dinkum_std::less<int> >,MEM_STL_ALLOCATOR<_Dinkum_std::pair<int,int> >,0> >::iterator> >::resize + 0x18e (fitter_vpr20kmain) 

0x12e22b: _cl_free_do_clustering_short_life_data + 0x15b (fitter_vpr20kmain) 

0x11cd36: _aa_flow_fit + 0x66 (fitter_vpr20kmain) 

0x10dc8d: _vpr_main_internal + 0x2ad (fitter_vpr20kmain) 

0x13b35a: VPR_QI_FACADE::vpr_qi_main + 0xfa (fitter_vpr20kmain) 

0x2cfaf: _fitapi_run_vpr + 0x6f (fitter_fitapi) 

0x38374: FITCC_EXPERT::run_vpr + 0xf4 (FITTER_FITCC) 

0x39f5f: FITCC_EXPERT::place_and_route + 0x13f (FITTER_FITCC) 

0x3bb1d: FITCC_EXPERT::invoke_fitter + 0x64d (FITTER_FITCC) 

0x4f88: _fcuda_execute + 0x1c8 (fitter_fcuda) 

0xa26b: fmain_start + 0x69b (FITTER_FMAIN) 

0x7835: qfit_execute_fit + 0x195 (quartus_fit) 

0x1179b: QFIT_FRAMEWORK::execute + 0x4ab (quartus_fit) 

0xfbb1: qexe_get_tcl_sub_option + 0x1641 (comp_qexe) 

0x1203b: qexe_process_cmdline_arguments + 0x3cb (comp_qexe) 

0x12123: qexe_standard_main + 0x83 (comp_qexe) 

0xb5be: qfit_main + 0x5e (quartus_fit) 

0x4d41: msg_main_thread + 0x11 (CCL_MSG) 

0x1be8: _thr_final_wrapper + 0x8 (ccl_thr) 

0x5425: msg_thread_wrapper + 0x85 (CCL_MSG) 

0x37f7: mem_thread_wrapper + 0x47 (ccl_mem) 

0x6051: msg_exe_main + 0x81 (CCL_MSG) 

0xb84c: _main + 0x1c (quartus_fit) 

0x13053: _memset + 0x15f (quartus_fit) 

0x4ed6b: BaseThreadInitThunk + 0x11 (kernel32) 

0x637f4: RtlInitializeExceptionChain + 0xee (ntdll) 

0x637c7: RtlInitializeExceptionChain + 0xc1 (ntdll) 

 

 

End-trace 

 

 

Quartus II 32-bit Version 12.1 Build 243 01/31/2013 SJ Web Edition 

Service Pack Installed: 1
0 Kudos
6 Replies
Altera_Forum
Honored Contributor II
2,440 Views

try deleting the db and incremental_db directories. 

Failing that, you may have to raise a service request via mysupport
0 Kudos
Altera_Forum
Honored Contributor II
2,440 Views

 

--- Quote Start ---  

try deleting the db and incremental_db directories. 

Failing that, you may have to raise a service request via mysupport 

--- Quote End ---  

 

 

Thanks for the comment. 

 

I raised a service request and got a very friendly response. While they didn't fix the problem, it did cause me to questions my Windows PC install - which lead to finding the real issue. 

 

*** Some feedback for other users who experience the same issue. *** 

 

It turns out, through experimentation, the demo project fails during Fit and Place very reliably for me when I run Quartus 32bit. It doesn't matter whether I was on Windows7 32 or 64bit, running Quartus 12.1sp1 build 243 (latest build) 32bit (the default installed binary), fails to compile the demo project. 

 

In Windows explorer, the default Quartus II binary associated with QPF project files is the 32bit version on a 64bit Windows install. Which hides the issue. 

 

However, compiling on 64bit quartus works very reliably, project compiles and no problem found. 

 

I've given this feedback on the service request so support can look into it. 

 

For anyone else with the problem, make sure you are compiling on 64bit windows with the 64bit binary as a workaround. 

 

Regards, 

 

- Steve
0 Kudos
Altera_Forum
Honored Contributor II
2,440 Views

Its probably to do with the memory requirements. I think that the min required memory (or at least min recommended) is 4GB. The most the 32bit exe can get is 3gb

0 Kudos
Altera_Forum
Honored Contributor II
2,440 Views

 

--- Quote Start ---  

Its probably to do with the memory requirements. I think that the min required memory (or at least min recommended) is 4GB. The most the 32bit exe can get is 3gb 

--- Quote End ---  

 

 

Quartus shouldn't crash though. 

 

I recently ran Quartus 11.1sp1 32-bit (WinXP) on a Stratix IV GX 530K design. Eventually the design failed with an out-of-memory error message. I then ran the same design on Quartus 12.1 32-bit (Win7) and it immediately gave an error message indicating to use the 64-bit version, which I did, and it synthesized fine. 

 

So there are clearly some error checks in place ... though I guess they are not thorough enough. 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
2,440 Views

>> It doesn't matter whether I was on Windows7 32 or 64bit, running Quartus 12.1sp1 build 243 (latest build) 32bit (the default installed binary), fails to compile the demo project. 

 

Did you try compiling the design with exact same Quartus version as the original ? You can figure that out by looking at the the original fit report in the synthesis directory (and also at the OS version that was used, and peak memory usage during fit).
0 Kudos
Altera_Forum
Honored Contributor II
2,440 Views

 

--- Quote Start ---  

>> It doesn't matter whether I was on Windows7 32 or 64bit, running Quartus 12.1sp1 build 243 (latest build) 32bit (the default installed binary), fails to compile the demo project. 

 

Did you try compiling the design with exact same Quartus version as the original ? You can figure that out by looking at the the original fit report in the synthesis directory (and also at the OS version that was used, and peak memory usage during fit). 

--- Quote End ---  

 

 

I didn't, although thanks for the tip. 

 

Altera Support did come back with a workaround, worth sharing here: 

 

Known issue on 32bit, will be fixed in v13. Workaround is to create a quartus.ini file in the project with vpr_disable_advanced_wire_maps=on. 

 

I've tried the fix on 32bit and it did compile correctly, apparently working around the original issue. 

 

It's not clear to me if this setting has any unwanted side effects and I didn't ask support. I'll not be using it, I'll stick with 64bit compiles, but a future reader may benefit. 

 

Many thanks to all who've offered advise. 

 

- Steve
0 Kudos
Reply