FPGA Compiler Bug

[LucianM]

While developing a driver for the NI-9853 CAN module I noticed that an indicator was written with an unexpected value. The TRUE case was executed but output "CAN Err Byte" was set to 0:

Code was executed on a cRIO-9035 using LabVIEW 2020SP1. Code is attached in zip file:

[Messenger2]

Hello LucianM,

Have you tried adding a small delay before "updating" the indicator? I recall indicators being unreliable sometimes. 

I'll try to replicate this soon.

[LucianM]

---

@Messenger2 wrote:

 I recall indicators being unreliable sometimes. 

---

I never heard about this and never had this issue but I tried with 1000us and 100ms delay and saw no changes. Indicator is still written with 0 instead of 1.

Thank you for looking into this!

[UliB]

I don't have FPGA, so I can't test, but it seems like a bug to me too.

Just an idea for a workaround: What happens if you insert a "Always Copy Function" after the constant?

[LucianM]

There is no "Always Copy" in FPGA module:)

[pimacchi]

Hello Lucian,

Have you found something else about this issue?

We are running in a very similar issue (except for we have an enum input and a boolean output). A brief recap:

- Our main VI is composed of different sections, each working with its own unique inputs and outputs

- Originally the VI was working as expected.

- In section "A" of the main FPGA VI, we added another istance of a subVI: we already had 9 instances and added the 10th.

- After compiling and running the VI, one boolean indicator (also connected to a DO) in the independent section "B" was stuck to TRUE, even when it should have been FALSE

- Running the same code on the RT or PC always gives FALSE

- If we remove the 10th instance from section "A" the problem disappears from section "B"

- Our current, slapdash fix is to add another subVI which does not change significantly the result, to section "A" (as an input to the 10th instance). This fixes the problem on section "B"

- The problem is repeatable and does not seem to be a fluke. We compiled several times frome two different computers (compile worker on NI cloud). The two sections do no share subvis and all the subvis are clones. All the code runs inside a SCTL.

My main concern is: this time the issue had little consequences because the product is still being tested, but how can I dare now making even the smallest (cosmetic or low impact) change to the code without retesting everything from scratches? Should I really question the independence of independent pieces of code???

[LucianM]

No, I thought @Messenger2 will open a ticket to R&D or something.

I rewrote a part of the VI and solved the issue but now every time I get a strange behavior I'm thinking if I made a mistake in my FPGA code or is another LabVIEW FPGA compilation issue.

[Newton_Petersen]

Hi @pimacchi, can you attach an example that demonstrates the problem you are seeing so we can help debug?

And Lucian, I'm glad you are not stuck anymore but I hope we can debug your issue too. My immediate suspicion is that we are either seeing a Xilinx tools synthesis bug OR a bug in the code behind some of those CAN IO nodes - but I have not reproduced or debugged yet. My first step beyond reproducing the issue is to try the newest version of the tools and ensure it isn't already fixed. Apologies for not noticing this thread sooner. If you need help figuring out how to get an escalation to R&D at NI, please reach out! (I honestly don't know how to do it but I get assigned a bunch of them so I know it is very possible and hopefully not too difficult to figure out:).

[pimacchi]

Hi Newton,

Thank you for your involvement!

I wish I already provided the example, but we cannot release the code as-is and the funny part about this bug is precisely that if you remove random unrelated parts of the code, the bug doesn't show up anymore.... However, we will try to provide an example, if we find a way.

As for the "newest version of the tool", we are actually working with LabVIEW FPGA 2024 Q3 on an sbRIO-9651 (no CAN tools involved). We are compiling on NI compile cloud. I am not sure that the CAN tools are important: in the end the problem described by Lucian shows up in a section of code that uses just plain Labiew code...

Thank you!

[pimacchi]

A quick update:

We were able to clean up the code a bit to have a relatively simple example with which we are opening a service request.

However we still need to include the CLIP and proprietary details and we cannot release it to the public. If you have a way to access the SR, I can PM you the reference number.

Thanks!