"LabVIEW FPGA: The compilation failed due to timing violations, but there is no path information because the timing violations are not of type PERIOD

[fabrizio_giorgetta]

The compilation of my labview fpga vi fails with the error message "LabVIEW FPGA:  The compilation failed due to timing violations, but there is no path information because the timing violations are not of type PERIOD".

In the 'final timing (place and route)' report, the requested frequencies are all below the maximum frequencies and the compilation error message is only displayed at the very end on the 'summary' page.

I tried to optimize my labview fpga vi with pipelining, but had no success.

Can anybody offer some advice on how to debug fpga code with this error? Is this really a timing error or something else?

Software:

Labview 2011, fpga 2011, xilinx tools 12.4 sp1

Hardware:

NI PXIe-1071 Chassis
NI PXIe-8108 Embedded controller
NI PXIe-7965R FPGA FlexRIO FPGA module
NI 5761 250 MS/s 14 bit Analog input digitizer

The Xilinx log of the compilation run is attached.

Also, this issue was already discussed in this thread ~6 months ago, but no satisfying answer was offered so far...

Thanks,

Fabrizio

[KHartley]

Fabrizio,

There should be an option to see more details about the error. Is there anything else that comes up, if there is can you post a screen shot? Also can you post a screen shot of your timing window from the compilation. Let me look into this a little more and if you can get the details back to me as quickly as possible that would be appreciated. 

[GerdW]

Hi Kyle,

I also get this error from time to time:

- No, there is no option to see details (apart from Xilinx log).

- This problem is hard to reproduce: I can compile a FPGA vi on one computer, but a second computer using the same LV version (and the same project settings ofcourse) produces the error shown above...

- I'm using LV2011SP1+RT+FPGA (DS1/2012)

[KHartley]

Fabrizio,

Could you attach your code or upload it to our ftp server? This could be a difficult error to trouble shoot if you could try to isolate a section of your code that reports the error that would be better on our end. Like in that other forum mentioned, rewriting the particular section may resolve the error. 

Are you using LabVIEW 2011 non SP1? Do you have access to a computer with 2011 SP1? Could you try compiling on that computer as well?

[fabrizio_giorgetta]

Below screen shots of the summary report (identical to GerdW) and the final timing report

I think I use non-SP1 (MAX->software->Labview: 11.0.0, MAX->software->Labview->FPGA: 11.0.0)

Kyle, would you recommend an upgrade to SP1?

I stripped down the code to a point where it compiles successfully (unfortunately losing some functionality) and plan to re-add bits of code until the compilation fails again. Obviously, this takes some time as I only know at the end of a 45 minute compilation run if it worked.I'll let you know as soon as I find out more (if I do...).

- Fabrizio

[KHartley]

Fabrizio,

Thank you for the reply. 

Yes that is LabVIEW 2011 non SP1.

LabVIEW 2011 SP1 may have resolved the issue but the error seems pretty generic right now and there may be some unknown instances. A better option is to figure out where the current system is failing then that will give me more specifics of what to look into. If you have the time in the future we recommend staying on the most current version of LabVIEW.

[KHartley]

GerdW,

If you could take similar steps to find the code that reports this error on your computer I can try compiling it on my system and see if my system reports the same error. Then I can look and see if it is a known issue that may have been resolved or a new issue I need to report.

[GerdW]

Hi Kyle,

the problem is: I have one computer which compiles the VI successfully and a second one which shows that error. Both use the same software setup (LV2011SP1+RT+FPGA from DS2012-01). Both use the same project file - atleast SVN shows no difference.

- You can have one FPGA VI where one computer is compiling successful and a second one complains. (Btw. I have a SRQ running in Germany on this topic.)

- More problems: After successful compiling on first computer and transferring all to second computer (using SVN, including the full project folder with all files like bitfiles, lvproj, and everything) the second computer is unable to start the RT executable due to error "FPGA VI needs to recompile". Solution so far: Call the FPGA-OpenReference with the bitfile instead of the VI (as I used to do until now)...

- More problems: After modifying the FPGA-OpenReference to use the bitfile (on the 2nd computer) and transferring all the files back to the 1st computer (using SVN as before, including the whole project) the 1st computer complains: FPGA-OpenReference is creating a different reference than is used in the VI. So what happens here? On one computer my VI is ok, the reference is typed correctly. Transferring all the files to a different computer the VI isn't ok anymore due to changes of the reference??? You know: all files are the same: lvproj, FPGA bitfile didn't change, cRIO reference didn't change...

All those problems didn't occur on my RT-FPGA projects in LV2010SP1. I'm not pleased...

[KHartley]

GerdW,

Can you post a MAX technical report of the two systems? Can you verify both systems are using the same compilations tools (ie 10.4, 11.5, or 12.4)?

Can you also post the Xilinx compilation log from both computers?

[GerdW]

Hi Kyle,

do you have access to my SRQ 7353713? So we could keep that discussion in one place - I would prefer the more "private" one of the SRQ...