LabVIEW FPGA - Xilinx memory error

[Charlie_P]

Good Afternoon noli,

I want to make sure that the error you are encountering is related to the size of your VI, rather than installed software or corrupt files on your PC.  Are you able to compile smaller FPGA VIs on this computer?  You can try a shipping example or something small that you create.  When you do this, watch your computer's memory usage.

Also, watch your memory usage when you compile your large program.  Does the memory usage jump up all at once?  Does it grow quickly?  Slowly?

[noli]

Hi,

  Yes, I manage to compile smaller applications with no problem, with RAM maxing out at around a few hundred MB.    For this big application that fails, ram usage doesn't explode all at once, but seems to grow slowly, and increases to around 2 GB when it starts the HDL synthesis about 2 hours into the compilation.  Then somewhere in between that and the next hour, it increases to 4GB.

   What I don't get.. is that if I can't compile a big vi, what's the point of purchasing a huge FPGA whose resources i'll never even be able to use?  The last time I sucessfully compiled this vi, it used about 30% slices, and I only added a few other functions between then and now.

   Also, why does the compiler need to use so much RAM in the first place?

[noli]

 I also tried removing all of the clusters (for the statechart) from the FPGA front panel, and leaving only  8 controls/indictators.  Still no luck.  It looks like whatever the problem is, its something that's happening inside of the statechart from the Statechart Module.  The most complicated things I'm doing there are 3 DDS triangle generations and 1 PID.   So.. the FPGA "should" be able to handle that no problem..  yet its not working

[Charlie_P]

Good Afternoon noli,

I am surprised to hear that you are having this much trouble with the compile process.  It is good that you removed the clusters from your Front Panel.

One thing to keep in mind is that although you were only using 30% of the slices in your previous compile, the slices do not directly translate to RAM usage.  It seems like your program just has some odd part in it that the compiler hangs on and keeps assigning memory, rather than behaving as expected.

Try removing parts of the code and compiling again.  The more that you can narrow down the origin of the error, the easier it will be to fix and remove.  Additionally, if there is some specific untested corner-case function in the Statechart Module that does not work properly with the FPGA compiler, we would certainly like to know about it.

[noli]

So there is ONE thing that I did which let me be able to comile my program..  but it isn't very helpful.  There was one state in the statechart I removed that had a disabled action..  and I deleted all the clusters (input/outputs) for the statechart.. and made them into constants -  just to test the compilation  When I set everything to a constant, the program compiled.  But when I then wired up controls and indicators and bundled those into the statechart input/output clusters, the compilation crashed again.

I am heavily using several FIFO's, 69% ram usage.  You mentioned ram in your last post, so do you think I should try cutting down on the size of those FIFO's?

Thanks

[EdH]

Hi noli,

It is my experience that pre-optimization to deal with the Xilinx compiler is a necessity to make many designs fit in the Xilinx compiler space. It is a slow, painful experience but valuable.

Use a LOOP to reduce complexity of the subVI and it may dramatically reduce the Xilinx compiler memory usage. Using on board memory and FIFO's to move data to and from the on board memory can save SLICEs. Keep the FIFO's small on the FPGA side to save SLICEs. Send data to and pull data from the on board memory in blocks if possible and use LOOPs to reduce Xilinx compiler memory usage.  If your subVIs are not going to execute in parallel have the subVIs compile as non-reentrant to force a single copy in the FPGA. Avoid ARRAYs on the FPGA if at all possible.

In a response to my earlier query, AE CHARLIE, Charlie Piazza, refered to some links. These are very useful references.

Good luck.

[Charlie_P]

Good Afternoon noli,

EdH brought up some good points.

Unused cases in a Case Structure should be removed before compiling for FPGA.  Likewise, I assume, states that are disabled should be removed before compiling.  Essentially, if a piece of code will never execute, it should not be sent to the compiler.  Even if the unnecessary code doesn't *confuse* the compiler, it is using additional space on the FPGA.

You said that the compiler crashed when you wired both objects (controls and indicators).  Do we know which is to blame?  Or is it the combination of the two?

[noli]

I don't know which of the two was at fault, but as each compile takes so long.. I don't really have time to experiment and find out.  I ended up shrinking my FIFO's to a really small size, which alone made no change.  Then I removed a huge concurrent substate that i'm not using now from the statechart, and it managed to compile.  Its unfortunate, because although i'm not using it now, I will need it eventually 😞   The weird thing is that with those changes, i'm now using relatively little FPGA space (again, the state I removed was not using much stuff).  

I'm going to try bit packing my boolean indicators, and as for the controls...  I have about 25 U16 and 9 FXP.  Would it be better to use global variables, or  maybe a strip of memory spots to send those values into the FPGA?  They're only used for configuring execution settings, not for high amounts of data transfer.

Despite all this, non of this (nor the links above)  really seems to explain why I can't compile something relatively non-trivial that doesn't even fill half of my FPGA space.   Maybe its time to push Xilinx for a 64-bit compiler??

Compilation Summary
-------------------

Logic Utilization:
 Number of Slice Registers:           6000  out of  51840    11% 
 Number of Slice LUTs:                9923  out of  51840    19% 
    Number used as Logic:             9917  out of  51840    19% 
    Number used as Memory:               6  out of  13440     0% 
       Number used as SRL:               6
Slice
Device Utilization Summary:
   Number of BUFGs                           3 out of 32      9%
   Number of DSP48Es                         4 out of 48      8%
   Number of ILOGICs                        49 out of 560     8%
   Number of External IOBs                 134 out of 440    30%
      Number of LOCed IOBs                 134 out of 134   100%
   Number of IODELAYs                       54 out of 560     9%
   Number of OLOGICs                        23 out of 560     4%
   Number of RAMB18X2s                       4 out of 96      4%
   Number of RAMB36_EXPs                     2 out of 96      2%
   Number of Slice Registers              5936 out of 51840  11%
      Number used as Flip Flops           5936
      Number used as Latches                 0
      Number used as LatchThrus              0
   Number of Slice LUTS                   9920 out of 51840  19%
   Number of Slice LUT-Flip Flop pairs   12207 out of 51840  23%

Clock Rates: (Requested rates are adjusted for jitter and accuracy)
  Base clock: 40 MHz Onboard Clock
      Requested Rate:      40.408938MHz
      Theoretical Maximum: 51.208521MHz
  Base clock: MiteClk (Used by non-diagram components)
      Requested Rate:      33.037101MHz
      Theoretical Maximum: 78.876794MHz
  Base clock: ReliableClk40 (Used by non-diagram components)
      Requested Rate:      40.408938MHz
      Theoretical Maximum: 194.893783MHz



Start Time: 7/8/2009 3:06:04 PM
End Time: 7/8/2009 6:21:46 PM

[Charlie_P]

Good Morning noli,

We have never seen a case quite like yours.  Is it possible to post your code so that we may try to compile it in house?  We are interested in the code that you originally tried to compile but were unable to--the version before you removed usused states, controls, and indicators.

If posting your code to the forum is not an option, we can continue troubleshooting via a Service Request handled through phone and e-mail.  Please let me know how you wish to proceed.

[noli]

Here you go..   Its a little hard to see whats happening in the charts just by looking at it (maybe a feature improvement for the next version?)  so just to summarize, there are PID vi's in the Engage Lock "X" Control substates, DDS Generation in the "X" Scan Substates, and FIFOs in the Aquisition/Transfer region.  Other than that, there  are mostly just simple triggers

Thanks