NI Labs

Showing results for 
Search instead for 
Did you mean: 

C Interface to LabVIEW FPGA



whatever I did, as you have mentioned, the result is still faulty operation. Please get attached file "" where is stored my original bitfile and then two test of "old" vs "new" C Interface to LabVIEW FPGA. To simplify investigation, I have used GCC distribution from NI FTP ( Goal of the both tests is to load bitfile with success. "Old" test is working fine, but "new" test fails. Source code is equal. There is bug either in "capigen.exe" or in "NiFpga.out" library. NOTE that I am able to build C Interface to LabVIEW FPGA examples, but they are very simple, so it does not mean the C Interface to LabVIEW FPGA is working correctly.


In addition search for included file "console.txt" where is LOG of execution of both test samples ("new" vs "old"). There you can se what is going on in debug console. My test system is sbRIO-9612.


Thanx for help in advance.

0 Kudos
Message 11 of 79



Thanks for the ZIP file. I found the problem. You're using controls/indicators that are type defs, but NiFpga.out does not yet have proper support for them.


As a work around, please try changing your "Instruction" control to be a simple type. You should be able to right-click on it and select "Disconnect from Type Def".

0 Kudos
Message 12 of 79



We do have some programmers in-house that prefers to use C#/.net, and not C/C++.  What are our options with regards to using a cRIO unit(e.g. 9012)?  Our application involves high speed synchronised sampling of ~17 channels, performing FFT, cross correlation calculations amongst all channels, filtering and signal processing.  Any programming of the FPGA would be through Labview FPGA.  However, will it e.g. be possible to make a main program structure in Labview RT, and then include/call algorithms made in C#?  (The paralell to Labview would be to include DLL's or C-code node in the labview main program). 



0 Kudos
Message 13 of 79



If I understand you correctly, you want to run .NET code written in C# on your 9012? I don't think that is possible, as I know of know .NET Framework that runs on LabVIEW Real-Time (VxWorks in this case).


You could, however, have a host application running in Windows using the FPGA Interface (either LabVIEW or C) which could probably call into .NET code. Is this maybe what you wanted?

0 Kudos
Message 14 of 79

Hi again,


I am playing with the "NiFpga_ReadArrayU8" / "NiFpga_WriteArrayU8" functions and seems to me, U8 data is treated as 4 Byte integers. I have stored data stream in byte order like this:


    EB3E 9056 5844 4F53 3132 0000 0201 0100


but function "NiFpga_ReadArrayU8" is swapping byte orde this way:


    5690 3EEB 534F 4458 0000 3231 0001 0102


I have identical code writen purely in LabVIEW and then under VxWorks C. I did the cross check using byte per byte approchch and I am pretty sure that problem is not in my code. If you generally handle arrays as U32, then "NiFpga.out" should handle it independently from used platform...


Could you please check it?


    Thanx in advance.


0 Kudos
Message 15 of 79
I was able to confirm this problem on my end (Nice catch!). I will correct the 8-bit and 16-bit calls to transfer arrays correctly on PowerPC targets and post a fix as soon as possible.
NI Software Engineer - RIO
0 Kudos
Message 16 of 79

Hi all,


playing around the C Interface to LabVIEW FPGA I found following behavior of "U8 Host to Target Fifo" operations. I did the following:


I have U8 FIFO buffer (host to target) of size 515 Bytes. I tried to write to this FIFO buffer data "per parts". First written block is 1 Byte, second block is 512 Bytes an last block is 2 Bytes. For each block is checked number of Empty Elements Remaining in the FIFO buffer. Writing 1 Byte I assume that remaining empty elements is 514. Then writing 512 Bytes I assume that remaining empty elements is 2. And finally writing last 2 Bytes there should be zero empty elements... but it does not. Result is, that every write takes the FIFO buffer as it was previously empty. The same I did in "C" under VxWorks and the same I did in LabVIEW. It behaves same way. My test system is sbRIO-9612, LabVIEW 8.6.


Please check attached project where is possible to see what is going on.

0 Kudos
Message 17 of 79

Re: Arrays: We are hoping to get a fix in soon. I'll post here when it's uploaded. Again, nice find!

Re: FIFOs: This is actually expected behavior, which is why you see the same behavior when using the LabVIEW FPGA Interface. The remaining elements parameter returns the number of elements left on the host memory side of the FIFO. So you have a 515 element deep FIFO on the host side due to a call to ConfigureFifo, but also a FIFO of X elements on the target side (configurable from the Properties of the FIFO in the LabVIEW Project). If you write enough elements to fill the target side of the FIFO you will see it back up to the host side, and the remaining elements will begin to shrink.
0 Kudos
Message 18 of 79



I have uploaded a new version which should fix the problem with arrays. Let me know how it goes!

0 Kudos
Message 19 of 79



 Thanks for the updated library. So far, all seems to work fine. Now I am more focused to the FIFOs. Arrays are not efficient for bigger amounts of data (it takes more FPGA resources and also compilation takes longer). As concerning speed of operations, it looks good for now. Good work. I am going to keep you informed if I find any unexpected behavior.


BTW do you expect to implement also Clusters soon?


0 Kudos
Message 20 of 79