Error (23031): Evaluation of Tcl script import_compile.tcl unsuccessful

[Altera_Forum]

Info: Command: quartus_cdb -t import_compile.tcl 

Info: Using INI file /home/temp/Desktop/workspace/wisconsin5/wisconsin5/bin/conv/quartus.ini Info (125061): Changed top-level design entity name to "top" Info (125061): Changed top-level design entity name to "kernel_system" Info (16677): Loading synthesized database Info (16734): Loading "synthesized" snapshot for partition "|". Info (16678): Successfully loaded synthesized database: elapsed time is 00:00:29 Error (23031): Evaluation of Tcl script import_compile.tcl unsuccessful Error: Quartus Prime Compiler Database Interface was unsuccessful. 1 error, 0 warnings  Error: Peak virtual memory: 12152 megabytes  Error: Processing ended: Wed Nov 15 01:19:43 2017  Error: Elapsed time: 10:30:25  Error: Total CPU time (on all processors): 11:41:19    I have this error in my quartus_sh_compile.log. But this only happens to my designs with large size (70% utilization). It will say 'failed to generate hardware' after around 10 hour's compilation. And by the way, the "<installation directory>/quartus/bin" directory was not in my PATH variable when that happend, but the hardware could be generated for this kernel with small size. I have the quartus_sh_compile.log and <kernel_name>.log attached.  aoc --version Intel(R) FPGA SDK for OpenCL(TM), 64-Bit Offline Compiler Version 16.1.0 Build 196 Copyright (C) 2016 Intel Corporation  quartus_map --version Quartus Prime Analysis & Synthesis Version 16.1.0 Build 196 10/24/2016 SJ Pro Edition Copyright (C) 2016 Intel Corporation. All rights reserved

[Altera_Forum]

Do you know if the fitter is completing successfully? That's the first thing to check. If it is completing successfully then read my next paragraph. 

 I had a similar problem with a newer version of the tool and increasing the size of my swapfile solved it. In my case I did some experiments and concluded quartus_sta couldn't allocate enough memory and error'd out and therefore certain file were not produced - which then resulted in import_compile.tcl failing because it was unable to find files that should have been generated. All my problems went away when I increased my swapfile size (I had 32 GB of physical RAM and 16 GB swapfile, I increased by swapfile to 48 GB ). I sized my memory to be larger than Intel's recommended build machine memory size for my FPGA. Your post provides the peak virtual memory value and it seems pretty low so that may not be the case, but I never looked at the peak virtual memory reported in the transcript when I had my issue; I found my solution by going through and running some of the quartus commands manually and noticed sometimes STA reported it ran out of virtual memory and failed.   Can you please post your *.flow.rpt file?

[Altera_Forum]

I do not see any useful information in the log as to why the compilation is failing. If this happens when the design gets too large, you are either running out of some resource on the FPGA, or you are running out of memory on your compilation machine. Check your top.fit.summary file to see if any of the resource utilization numbers is over 100%, or far too low, the latter showing overflowing of the resource utilization numbers.

[Altera_Forum]

I checked the compilation log file, and my top fitting is not finished. Thus the top.fit.summary is not generated.

[Altera_Forum]

Based on the quartus_sh_compile log, fitting has actually finished successfully. Sort the files in the compilation folder by date and check the last files and see what logs where written to at the end, before the compilation crashed.

[Altera_Forum]

I checked, the top fitter has not completed. But according to my optimization report, the 2 attributes of my utilization are around 70% and the other two are 40% and 50%. If I over used the board, can actual resource utilization differ this much with estimation? And I only have the base.flow.rpt (base fitting was finished, but not top fitting).

[Altera_Forum]

Hi HRZ, 

 The fitting that was successful was the base fitting, there are supposed to be two fitting (top and base), you can check it in your compiled kernel designs, there are supposed to be 2 lines of "Quartus Prime Fitter was successful." and I only have one

[Altera_Forum]

On Arria 10, the resource utilization estimation can be up to 50% off. Maybe your problem is memory after all. How much memory does your compilation machine have?

[Altera_Forum]

I guess you are right HRZ. I have 32 GB RAM on my PC, and the peak virtual memory of my compilation is around 12 GB. Now without any process going on, my RAM usage is 26GB (my operating system is a bit screwed up)

[Altera_Forum]

Hi HRZ, I rebooted my PC and launched another compilation. According to the "top" command, now my quartus fitting is taking 70% RAM... and according to "free -m" command I only got a few hundreds megabytes unused RAM now. (I have 32GB RAM). Does this amount of RAM consumption happen to you before?

[Altera_Forum]

That is pretty normal, the placement and routing process is very memory intensive. Altera recommend 18-48 GB memory for Arria 10. The bigger your design is, the more memory it will need. I have seen the process taking up over 40 GB memory.

[Altera_Forum]

I see. So if the fitter crushes due to RAM limit, the log file would not say any thing about that?

[Altera_Forum]

Hi  

 Can you confirm if your BSP version(if not Altera's board) is match with the SDK version? This error usually link to version miss match.  Regards, CloseCL (This message was posted on behalf of Intel Corporation)

[Altera_Forum]

Hi, 

 Thanks for your reply! I am using altera arria10soc, and below is the board_env_xml,   <board_env version="16.1" name="altera_a10socdk"><hardware dir="hardware" default="a10soc"/><platform name="arm32"><linkflags>-L%b/arm32/lib</linkflags><linklibs>-lalterahalmmd -lalterammdpcie</linklibs><utilbindir>%b/arm32/bin</utilbindir></platform><platform name="linux64"><linkflags>-L%b/arm32/lib -L%a/host/arm32/lib</linkflags><linklibs>-lalterahalmmd -lalterammdpcie</linklibs><utilbindir>%b/arm32/bin</utilbindir></platform><platform name="windows64"><linkflags>-L%b\arm32\lib</linkflags><linklibs>-lalterahalmmd -lalterammdpcie</linklibs><utilbindir>%b\arm32\bin</utilbindir></platform></board_env>   And below is my aoc version   Intel(R) FPGA SDK for OpenCL(TM), 64-Bit Offline Compiler Version 16.1.0 Build 196 Copyright (C) 2016 Intel Corporation   They are all 16.1. (It just cannot finish for a larger size of the design so I think the version should not be the problem?)   Regards, Lancer

[Altera_Forum]

--- Quote Start ---  I see. So if the fitter crushes due to RAM limit, the log file would not say any thing about that?  --- Quote End ---    It usually does, but I think there might be cases where it doesn't. If you experience this crash only for large designs, it is certainly not due to Quartus/AOC/BSP version mismatch. As dark_visage suggested, you can try increasing your swap and see what happens. Furthermore, make sure you have the maximum possible amount of free memory before running the compilation. Finally, You can try updating your Quartus and AOC to v16.1.2.

[Altera_Forum]

Thanks for your following up! Yesterday I cleared the RAM and compiled again. The compilation did not crash, but it's still processing until now (it has taken 24+ hours).