Hardware Developers Community - NI sbRIO & SOM

cancel
Showing results for 
Search instead for 
Did you mean: 

FPGA compile timing error

Hi,

I upgraded from LV2014 to 2015, and my FPGA VI do no longer compile. I get a "A iming error occured" message in the compilation status, and reports "LabVIEW FPGA:  The compilation failed due to timing violations."

I'm using sbRIO9651, and under LV2014 my VI just compiles fine.

Should i modify something in my FPGA VI to get it copiling under LV2015 or is there something i missed.

Thank you

0 Kudos
Message 1 of 8
(8,550 Views)

There is a button on the compilation window that allows you to investigate timing errors.  What are the block diagram items that are failing timing?  Can you send a screen shot?

-TD

0 Kudos
Message 2 of 8
(7,560 Views)

Hi,

Investigate timing violation button shows this window.

Capture.PNG

0 Kudos
Message 3 of 8
(7,560 Views)

This is a project that used a CLIP with secondary ethernet, wasn't it?

The newer version of Vivado changed how it synthesizes our secondary ethernet embedded in the CLIP and so our 2014 version of secondary ethernet was no longer valid in LV FPGA 2015. Our 2015 CLIP Generator generates correct code for LV FPGA 2015. If you try to apply your 2014 CLIP in 2015 LV FPGA it would've given you a warning, but since you upgraded your project instead of building it from scratch, you weren't warned before this happened.

I believe we tested backwards compatibility and so I think 2015 secondary ethernet works with LV FPGA 2014, but I'm not 100% sure. I don't think we can guarantee that we will always be able to create backwards compatible CLIPs though.

Originally we assumed that 9651 CLIPs didn't need to be versioned because the VHDL that is valid today would still be valid tomorrow, but components like secondary ethernet have pretty tight timing constraints so small changes in Vivado can cause it to fail timing.  The 2015 secondary ethernet was written a little more carefully to try to be more future-proof but every new version of Vivado could potentially break it again.

This breakage forced us to create a new version of the DevKit CLIP, which is why there is now DevKit2.

If you launch the CLIP Generator from the windows start menu (as opposed to the LV project), then you can create CLIPs that target different versions of LabVIEW FPGA, in case you need to use the old secondary ethernet implementation for some reason.

0 Kudos
Message 4 of 8
(7,560 Views)

nturley,

This would have REALLY burned us with builds on our ( dozen? ) SoM projects when migrating to 2015.  Where is this documented?  Why am I reading about it on the forums and not being sent an email or reading it in a change log?  What else is there that is broken like this that will make me and my team spin our wheels on?

We have dozens of CLIPS that all need to upgraded/updated if this is the case.  As much as I'd love to read every forum post, it's not realistic.  There needs to be a better way to get this information from the engineers at NI to the people using your products.  If this was sent out as a "things you may need to be looking into before we release version XXX of the LabVIEW tools" document months ahead of the software release, that would greatly reduce frustration and waisted revenue.

Please pass this on to those who can work to improve this process.

-TD

0 Kudos
Message 5 of 8
(7,560 Views)

Hi tduffy,

I agree this is very frustrating, and the error manifests in a way that is difficult to track down and fix if you run into it. All of us at NI desired to avoid this issue, but one of the caveats of NI exposing parts of our internal VHDL to users (in the Socketed CLIP) is increased user exposure to the tweaks, changes, and compatibilies of our vendor's compiler.  On other Zynq targets at NI, we can automatically adjust these timing constraints on our dynamically generated VHDL to account for the changes and evolution in Vivado.

Because you asked, I will point to where it is documented. This issue is documented in the NI-RIO (August 2015) known issues document (CAR 520628) that is linked from the NI CompactRIO Device Drivers August 2015 Readme (check known issues section).

"A socketed CLIP created from LabVIEW 2014 for the sbRIO-9651 System on Module that includes the secondary Ethernet port will not compile with LabVIEW 2015."

"A socketed CLIP created in LabVIEW 2014 for the sbRIO-9651 System on Module that includes the secondary Ethernet port will fail to compile due to timing violations in LabVIEW 2015.

Due to changes in the LabVIEW 2015 FPGA Module, you must regenerate a socketed CLIP if you require the secondary Ethernet port enabled.

Workaround:

To update your socketed CLIP for LabVIEW 2015, run the sbRIO CLIP Generatorfrom the Start Menu. You can select you Socketed CLIP configuration from the drop down box and use the LabVIEW Version dropdown to select 2.0 (LabVIEW 2015). Once you’ve finished updating your configuration your bitfile should successfully compile."

I understand that not everyone (most people, perhaps) don't read release notes before upgrading, but I believe publishing these issues in this way is industry best practice.

One of the issues with release notes is they often capture the issues that are caught near the end of product development, so they are published at or near the release time of the software.  This document was published in August 2015 with the release of the updated RIO device drivers.

Regards,

spex

Spex
National Instruments

To the pessimist, the glass is half empty; to the optimist, the glass is half full; to the engineer, the glass is twice as big as it needs to be has a 2x safety factor...
Message 6 of 8
(7,560 Views)

Hi all,

Thanks to everyone.

Indeed, i regenerated my socketed CLIP under LV2015, and now my VI compiles fine.

Regards,

Bachir

0 Kudos
Message 7 of 8
(7,560 Views)

                            

0 Kudos
Message 8 of 8
(5,826 Views)