LVOOP classes in FPGA VIs: some encountered problems

[dlanger]

I built a LVOOP class that I would like to re-use on different FPGA VIs. It's wonderful that LVOOP classes can be used on FPGA targets in the first place!!

However, my initial enthusiasm was severely dampened by the fact that my LV 2010 (SP1) was constantly causing problems during compilation:

• crashes most of the time
• if there was no crash, it told me an error message stating that the class could not be statically resolved. Aristos Queue states in an LAVA article, "Dynamic dispatching is entirely folded out in the compiler -- if we cannot resolve it to a static dispatch at compile time, the VI returns a compile error". In some of my attempts, I used LVOOP inheritance with dynamic dispatch methods; however, I am sure that should have been possible to resolve them at compile time!

Hoping that these bugs are fixed in LV2011, I opened the project there. At least, it doesn't crash anymore during compilation, but now I am confronted with another error message: "FPGA targets do not support classes that contain the refnum data type." That was a big disappointment as my original LVOOP class provides functionailty for an on-board buffer that should help me to prevent buffer overflows in the FPGA-to-host FIFO buffer (see attachments for LV2011 and LV2010 versions of the class). With the aim to create a class than can be flexible used with different memory sizes, I used a FPGA memory reference that can be created in the FPGA main VI with the VI-Defined Memory Configuration [nirviLrmPalette_MergeVI_Memory.vi].

Can anybody explain me, why the refnum data type should be a problem on FPGA targets? I just would like to understand...

[dlanger]

My attempt to do it without LVOOP also failed. I now put all the previous object data into a cluster that his handed on between different VIs (corresponding to the previous class methods).

I have to keep the cluster values in a shift register of a loop in the FPGA main VI. The error message causing a broken main VI is: "Shift Register: Possibility of Dynamic Refnum not supported for current target. Details: Refnums must be constant references in the current target. This construct could potentially cause a reference to be dynamic."

This, again, does not make sense to me as the memory references are type-bound to the underlying data type stored in the FPGA memory (U16) in my case.

See attachment for the library now replacing the original class (LV2010 code).

[Dan_N]

Hi dlanger,

First, sorry about the delay in getting back to you. I've done some looking into this issue, and the issue here is with how the refnum translates onto the FPGA. Specifically, when you place a reference to memory in your FPGA code, the connection between that memory and the code accessing it is hardwired by the FPGA. Placing a memory reference into a shift register or a class creates the possibility that the memory reference could change to point at a different block of memory during the program's operation. FPGAs cannot be reprogrammed dynamically, which is why you're receiving those error messages.

Please post back if you have any additional questions.

[dlanger]

Thanks, Dan! This explanation makes sense.

[Dan_N]

Glad I could help out!

[Dragis]

Back to your original post ... there are several known issues with class support in the FPGA module, specifically in LabVIEW 2010 and 2011. I would suggest not using classes for the FPGA right now to keep from getting bit by subtle bugs. However, you should see fixes for these issues as well as new features for classes on the FPGA in a (near) future version of LabVIEW ; )