LabVIEW FPGA - Xilinx memory error

[Mr._Jim]

Hello,

I'm compiling a substantial FPGA application that uses a lot of fancy fixed point math.  Everything is fine until about two hours into the compilation.  At that point, I've gotten this error twice:

ERROR:Portability:3 - This Xilinx application has run out of memory or has encountered a memory conflict.  Current memory usage is 2005956 kb.  Memory problems may require a simple increase in available system memory, or possibly a fix to the software or a special workaround.  To troubleshoot or remedy the problem, first:  Try increasing your system's RAM.  Alternatively, you may try increasing your system's virtual memory or swap space.  If this does not fix the problem, please try the following:  Search the Answers Database at support.xilinx.com to locate information on this error message.  If neither of the above resources produces an available solution, please use Web Support to open a case with Xilinx Technical Support off of support.xilinx.com.  As it is likely that this may be an unforeseen problem, please be prepared to submit relevant design files if necessary.
ERROR:Xflow - Program xst returned error code 19. Aborting flow execution...

I changed Windows' paging file to a maximum of 8 GB (see screenshot for exact settings), hoping that this would solve the issue, but the problem has returned for a second time.  I'm running on a Pentium 4 3 GHz with 2 GB of RAM.  I'm wondering if I've simply set up the paging file wrong.  Any advice?

Thanks very much,

Jim

[SamboNI]

Hi Jim,

Is your program using the new LabVIEW FPGA 8.5 I/O node controls, and lots of them? Are many, many intermediate files being created?

We have seen this issue crop up with a couple of customers already, and we are working with R&D to find some solid guidelines to give people to eliminate this issue.

If you like, you may post your code and we can give you feedback on things you may be able to modify to remedy this.

Best regards,

[Mr._Jim]

Hi Sam,

Yes, I'm using LabVIEW FPGA 8.5, and I'm using a significant amount of nodes.  I have three cRIO-9151 expansion chassis full of a lot of different modules.  To give you an idea of what I'm doing, I'm taking analog input for 44 channels and scaling them to engineering units using fixed point math.  It's a heck of a lot, but I didn't expect to get an error like this.  If anything, I half expected to run out of fabric.

Unfortunately, I can't post the code due to its proprietary nature.  I did post a screenshot, however, that should give you an idea of what I'm getting into.

Please, if you have any guidelines, I would love to hear them - I'd rather not waste any more hours on failed compilations.

Thanks,

Jim

[Vinay_Kumar]

Hi Jim,

This link might be helpful !  http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=14932

Message Edited by Vinay Kumar on 10-15-2007 02:01 AM

[Mr._Jim]

Thanks Vinay,

That actually is very helpful - NI support gave me the same recommendation, too.  Too bad WinXP 32 can't address more memory...

Jim

[WillD]

I am having this same issue.  My main vi currently has 32 seperate I/O nodes of 4 elements each, this will be expanding.

I am running the compile server on a 4core Xeon 5140 2.33GHz box with WinXP64 and 8GB of RAM.

Best Regards,

William

Edit: Here is a link at Xilinx that describes a work around, if the user had any control over the compilation process.

http://www.xilinx.com/support/answers/15336.htm

Message Edited by WillD on 02-22-2008 08:10 AM

[Jimmie_A.]

Hello,

Some customers have been using so called 'Free RAM' applications succesfully when this error occurs, have you tried it out? Usually in the form of VBScripts one can run in order to free RAM.

I did some searches on download.com and found multiple similar applications where some of them have received really good ratings by the editors as well as the users.

Hope this helps,

[WillD]

I just attempted to compile 1/4 of my final project and the compilation failed.  It did make it farther, into the HDL Advanced Synthesis, but failed within the FSM extraction as outlined in the link I gave previously.

When would you propose I use a Free RAM application?  I compile off of a fresh reboot and xst.exe has used up to 3GB of RAM but no more of the 8GB total.

[CarlaU]

Hi WillD,

There are a few good websites that I can point you to regarding the use of the free RAM optimizer. I have not used it myself but from other sources, I hear that it has helped with this issue. Have you also looked at the link above that goes to the Xlinx website? That also might be a great resource. There is also a great knowledgebase article that discusses how to use virtual memory to help alleviate memory issues with LabVIEW, which might help.

[mdevoe]

Normally 32 bit Windows XP will divide the total memory equally between the OS and user processes, however with the /3GB switch in the boot.ini file it will only reserve 1 Gb for itself. This means that any single process can only use up to 3 Gb of memory.

XP64 can see way more memory, but in order for a process to use it, the app must also be 64 bit otherwise it can only address 4 Gb (I think). All the Xilinx tools that are distributed with LabVIEW FPGA are 32 bit, so even moving to XP64 would have limited benefits.

What FPGA/target are you compiling to? Using that much memory that early in the compile stage seems almost excessive - are you sure you don't have the FPGA over mapped? That could easily make it take way more memory and time to synthisize and it would fail in place and route.