xilinx log warnings

[johnoc]

I was going through my xilinx log file after a successful build and saw that there were many WARNINGS. Thousands actually. I have attached a file with a few of the initial warnings. I have also attached the entire log file. Should these warnings concern me? Will they cause me problems? Many of the warnings seem to be at the compiler level on built-in HDL files.

[ANDROID_FREEBOT]

Hi johnoc

What software and hardware are you using?

[Jacobson-ni]

In general, warnings in the Xilinx log are fine as long as everything compiles. Errors in the log are what you should look for but the VI probably won't compile if there is an error.

[johnoc]

Hi Andy,

LabVIEW 2014 SP1

sbRIO-9636

[DangerDave]

Hi John,

Is there any other indication that your program is not functioning correctly? Are you seeing any unusual behavior?  Based on what Matt said, if there is no other evidence for a problem, warnings in the log are fine.

David

[Hooovahh]

I think you already have your answer, but I wanted to give an example of when a warning means nothing at all.  So when makeing and FPGA compilation LabVIEW needs to route all the code you wrote into a FPGA bit file.  This routing tends to take up most of the time for an FPGA compile and involves alot of magic I'm not familiar with, with the Xilinx compiler.  But what I do know is that this routing takes up resources.  This involves using up gates, multipliers, memory components, look up tables, etc.  Your FPGA has a limited amount of each of these resources and the compile will fail if you run out of any resource, or if timing can't be achieved.  Timing is an interesting one because data needs to go from one part of the FPGA to another in the time specified by how the code was written.  With this there is a propagation delay by going through gates, and physical separation between points on the board can cause delays.

LabVIEW needs to find the most efficient way to plot down the routes in the FPGA so that the code does what you want, and doesn't go over any of the resources mentioned, while meeting timing.  But there is also this struggle of doing it quickly.  LabVIEW could take hours to get the most efficient FPGA compilation taking up only 10% of the resources.  Or it could come up with a route that functionally is the same, takes up 50% of the resources and only takes a few minutes to compile.

So when compiling LabVIEW will first try the semi-inefficient method hoping to meet timing, and resourcing while making compilation time low.  But in this you may see warnings that the compilation is using more than 100% of a resource like gates.  Or you may see it give a warning that your timing can't be maintained, where your clock speed generated will be less than the one you specified.  If these warnings happen LabVIEW will go back and try to re-route the code in a way that is more efficient.  I have on a couple of occasions seen a compilation say it will use up 140% of the available gates, but after a couple of hours of optimizing, it all fit in 99%.  It is just one of the examples where a warning on a compile is fine, as long as the output is a successful compile. 

[johnoc]

The FPGA code seems to be working just fine, with the exception of my own mistakes. I come from the land of the written languages and am somewhat OCD about compiler warnings and such. Even though they aren't usually serious I try and get rid of all of them as a matter of practice.

Thank you all for your inputs!