LabVIEW Embedded

Showing results for 
Search instead for 
Did you mean: 

Labview FPGA compile server




I have a problem with LabVIEW FPGA Xilinx compilation server.

I have to compile a pretty complex VI, but the compile server aborts the compilation and gives no explanaitions.

Is it possible that the compiler is unable to compile too complex VI?




Labview FPGA compiler.PNG


0 Kudos
Message 1 of 14



If you try to compile a blank FPGA VI, do you run into the same error? I have not seen problems come up from a VI being too complex other than standard timing or resource violations. I would definitely try comiling a blank VI but some other questions that might help us figure out what is going on.


1. Are  you compiling on your computer locally, the cloud, or your own compile server?

2. What target are you trying to compile for?

3. What stage of the compilation do you reach before it is aborted and about how much time is this? Is this always the same?

4. Can you attach the Xilinx log (this should be located under C:\NIFPGA\Compilation or C:\NIFPGA\Jobs)

5. Do you have active firewalls or antivirus?

Matt J
National Instruments | CLA
Message 2 of 14

I think this error is connected with and caused by the use of DSP48E for realization of multiplication, but not with the size of VI.


1. I'm compiling on my local computer.

2. Target PXIe-7966R

3. Stage - Pre-synthesis, it gave several times the same result (haven't tried more).

4. I have no Xilinx log file.

5. No, I don't have activee firewalls, but active antivirus.


If my problem is connected with DSP48E usage, then I have another question - how to use the DSP48E correctly for my target? What are the settings, because till now I have only failed.

Here is part of my VI what I wish to implement.



Thank you for your response.





0 Kudos
Message 3 of 14

@chikenene wrote:

I think this error is connected with and caused by the use of DSP48E for realization of multiplication, but not with the size of VI.




Does this mean that you are able to compile other VIs but not ones that use the DSP48E blocks?


Could you also attach the VI for the image you put in your previous post? I tried to reproduce the issue on my end but was unable to do so. This could be because I was compiling on the cloud or did not have the DSP48E blocks configured the same way. If you can post a VI that aborts on your end and tell me which LabVIEW version you are using I can try reproducing it on my end.

Matt J
National Instruments | CLA
Message 4 of 14

The originally compiled Vi consists of 32 subVIs, thus not possible to post it here.


I am using LabVIEW '13.


Now I want to solve this problem first - DSP48E correct implemenation - and see if this is what caused the big one.

And all the used DSP48E are set like this:


0 Kudos
Message 5 of 14

It didn't error out when I tried it in LabVIEW 2015 (I don't have a 2013 computer set up right now). 


Can you compile the part of the VI that you posted in the image? Even if it is part of a bigger VI, you should be able to compile what you showed me in the image. If it aborts the code in the image, can you post that single VI?

Matt J
National Instruments | CLA
0 Kudos
Message 6 of 14

I created a new project with my Target and added the VI (in attachment).

Now this VI is compiled successfully, but there is still problem with the resources, because DSP48s is 0%, but in my vi there are 4 DSP48E.


Here is the compilation result.

Compilation results.PNG

0 Kudos
Message 7 of 14



Are you able to run this compiled code? I was also able to compile this VI on my end. It does say 0,0% DSP48s used, but since this VI compiles, it probably isn’t causing the original abort error. I’ve included a link to the NI Support Manual for configuring DSP48s so you can ensure they are configured correctly for your application.


 You mentioned that you have quite a few subVIs—can you individually compile those? It would be a good troubleshooting step to individually compile the VIs, so we can narrow down what is causing the compile to abort.



0 Kudos
Message 8 of 14

Hi chikenene,


I agree with aprillest. The DSP48 usage you are seeing is probably unrelated.


However, I wanted to give some insight into why you aren't seeing any DSP's being used. The code you have attached has your DSP48's running in an infinite While Loop. The output of these nodes are wired to an indicator outside of the loop. LabVIEW sees this as an unreachable state and optimizes the nodes out of the code and thus they do not get compiled. To demonstrate, try adding an indicator inside the loop. You should then see DSP usage on the resource utilization on next compile. ...Or, alternatively, try compiling a similar VI with nothing in the loop (no nodes) and notice that the resource utilization is nearly the same (a blank VI will also be similar). 


An alternative fix for the code you have is to create and wire the appropriate constant/control to the Loop Condition of the loop to allow for an exit out of the loop.


David C
Message 9 of 14

Thanks for your answers.


At the moment I have come to a conlusion:

a) I can compile successfuly this VI - it shows the number of used DSP


b) when I want to compile vi given in the picture as subVI, it says that it is not allowed to have indicators crossing clock domains.


c) when I take the indicator outside the timed loop, the compilators final result shows no DSP used.


I am stuck in this problem! Does someone knows the solution?



0 Kudos
Message 10 of 14