Long compile time for FPGA VI

[crdvis16]

In the past I have compiled a number of relatively simple FPGA VIs that typically took around 15 minutes.  These were usually VIs that used a few channels on 1 or 2 cRIO devices.  However, I am now trying to compile an FPGA VI that uses almost every channel of the following cRIO modules:

9485

9477

9476

9403

9207

9217 x 2

Additionally, many of the individual channels on some of the modules each require their own timing loop (in all I have 40 seperate while loops).  I expected that the compile time would be significantly longer- somewhere in the ballpark of 3 hours or so.  However, the compiler is going on 24 hours now and hasn't made all that much progress.  I've attached the Xilinx log as of 23 hours 47 minutes in case that might shed some light on why it is taking so long.

While trying to see if others have had similar problems I noticed that the compile process could be RAM intensive and might result in page file usage that could slow the process down quite a bit.  Looking at the task manager the page file usage is sitting at about 3GB and the process "xst.exe" is taking up around 1.3GB of RAM (the computer has 3GB total).  I'm not sure if that may have something to do with it.

If RAM is the issue, I'm wondering if there is a way to know how much RAM my computer needs in order to compile in a more reasonable time (something less than 8 hours or so).  Also, is there a way to break up the compilation into smaller pieces?  I was thinking it would be possible to break my FPGA VI into smaller pieces and compile them seperately (creating separate bit files) but as far as I know the FPGA can only have a single bit file loaded at a time.  I would need all the bitfiles to be able to run at the same time so am I correct in thinking this is not a solution for me?

~Clinton Davis

[WillD]

One quick idea without looking at your code:  I had to minimize the number of I/O nodes in my FPGA code.  I had to go so far as using a loop to read a bunch of I/O and just write it to globals, then operate on the globals in my 32 other loops.  It is the way LabVIEW generates the I/O code that gets compiled that is troublesome.  It is better to have 3 I/O nodes with 30 elements than 10 I/O nodes with 9 elements.

[jareds]

Clinton,

Most likely your VI barely fit (or didn't fit) on the FPGA.  When this is the case the compiler can take much longer, since it will be trying many different combinations to get the code to fit on the FPGA.

Also, you are correct in thinking you can only use one bit file for an FPGA.  Since the compiler needs to divide the resources of the FPGA among all the components of your code, it needs to compile on all of the code so it can know what has and hasn't been used already. 

[crdvis16]

Is there a way to figure out how much space an FPGA VI will take up on the FPGA?  If I knew that then I could think about buying an FPGA with enough memory.

[crdvis16]

Referring to my previous post, I found a knowledge base article that talked about compiling portions of your full FPGA VI in order to see how much each piece contributes to the total space required.  It says that the % of slices used that is reported at the end of a successful compile is a good estimate to use.  I'm working on compiling each piece now to see what my total requirement might be (one of my subVIs already compiled successfully and used 75% of the total slices).

I now have another question- is the storage space or the memory of the FPGA controller the limiting factor?  My 9002 controller has 32MB DRAM and 64MB flash storage.  If I am going to buy another controller I would need to know which (or both?) of these needs to be significantly larger. 

[WillD]

The FPGA code is compiled for the backplane you are using, therefore the size of the backplane is the limitting factor.  A NI-9103 will hold more code than a NI-9101; NI-9113 more than a NI-9111, etc...

[jareds]

Clinton,

The limiting factor is the resources on the FPGA itself.  Depending on what's in your VI, it will require a certain number of resources from the FPGA.  A good resource on how to optimize your code to take up fewer resources is here: http://digital.ni.com/public.nsf/allkb/311C18E2D635FA338625714700664816?OpenDocument.